Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladimir Davydov <vdavydov.dev@gmail.com>
To: Kirill Shcherbatov <kshcherbatov@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: Re: [PATCH v5 1/4] box: introduce tuple_format_iterator class
Date: Mon, 6 May 2019 16:55:55 +0300	[thread overview]
Message-ID: <20190506135555.wgtewxgznfta3uss@esperanza> (raw)
In-Reply-To: <0e9e576a96eadd8bf20de1ffe3635ac543d9de9c.1557142159.git.kshcherbatov@tarantool.org>

On Mon, May 06, 2019 at 02:57:38PM +0300, Kirill Shcherbatov wrote:
> The similar code in tuple_field_map_create and
> vy_stmt_new_surrogate_delete_raw that performs tuple decode
> with tuple_format has been refactored as reusable
> tuple_format_iterator class.
> 
> Being thus encapsulated, this code will be uniformly managed and
> extended in the further patches in scope of multikey indexes.
> 
> Extended engine/json test with vy_stmt_new_surrogate_delete_raw
> corner case test. There was no problem before this patch, but
> small bug appeared during tuple_format_iterator_next
> implementation was not covered.
> 
> Needed for #1257
> ---
>  src/box/tuple_format.c    | 356 ++++++++++++++++++++------------------
>  src/box/tuple_format.h    | 118 +++++++++++++
>  src/box/vy_stmt.c         | 117 +++++--------
>  test/engine/json.result   |  17 ++
>  test/engine/json.test.lua |   5 +
>  5 files changed, 371 insertions(+), 242 deletions(-)

Looks good. See a few really minor nit picks below.

> 
> diff --git a/src/box/tuple_format.c b/src/box/tuple_format.c
> index 804a678a1..de48e9bb0 100644
> --- a/src/box/tuple_format.c
> +++ b/src/box/tuple_format.c
> @@ -1033,3 +883,179 @@ box_tuple_format_unref(box_tuple_format_t *format)
>  	tuple_format_unref(format);
>  }
>  
> +int
> +tuple_format_iterator_create(struct tuple_format_iterator *it,
> +			     struct tuple_format *format, const char *tuple,
> +			     uint8_t flags, uint32_t *defined_field_count,
> +			     struct region *region)
> +{
> +	assert(mp_typeof(*tuple) == MP_ARRAY);
> +	*defined_field_count = mp_decode_array(&tuple);
> +	bool validate = flags & TUPLE_FORMAT_ITERATOR_VALIDATE;
> +	if (validate && format->exact_field_count > 0 &&
> +	    format->exact_field_count != *defined_field_count) {
> +		diag_set(ClientError, ER_EXACT_FIELD_COUNT,
> +			 (unsigned) *defined_field_count,
> +			 (unsigned) format->exact_field_count);
> +		return -1;
> +	}
> +	it->parent = &format->fields.root;
> +	it->format = format;
> +	it->pos = tuple;
> +	it->flags = flags;
> +	it->required_fields = NULL;
> +	it->required_fields_sz = 0;
> +
> +	uint32_t frames_sz = format->fields_depth * sizeof(struct mp_frame);
> +	if (validate)
> +		it->required_fields_sz = bitmap_size(format->total_field_count);
> +	uint32_t total_sz = frames_sz + 2 * it->required_fields_sz;

2 * ?

Shouldn't this be a part of the next patch?

> +	struct mp_frame *frames = region_alloc(region, total_sz);
> +	if (frames == NULL) {
> +		diag_set(OutOfMemory, total_sz, "region",
> +			 "tuple_format_iterator");
> +		return -1;
> +	}
> +	mp_stack_create(&it->stack, format->fields_depth, frames);
> +	*defined_field_count = MIN(*defined_field_count, validate ?

Shouldn't we use KEY_PARTS_ONLY here rather than VALIDATE?

> +				   tuple_format_field_count(format) :
> +				   format->index_field_count);
> +	mp_stack_push(&it->stack, MP_ARRAY, *defined_field_count);
> +
> +	if (validate) {
> +		it->required_fields = (char *)frames + frames_sz;
> +		memcpy(it->required_fields, format->required_fields,
> +		       it->required_fields_sz);
> +	}
> +	return 0;
> +}
> +
> +/**
> + * Scan required_fields bitmap and raise error when it is
> + * non-empty.
> + * @sa format:required_fields and field:multikey_required_fields
> + * definition.

There's no such thing as multikey_required_fields yet.

> + */
> +static int
> +tuple_format_required_fields_validate(struct tuple_format *format,
> +				      void *required_fields,
> +				      uint32_t required_fields_sz)
> +{
> +	struct bit_iterator it;
> +	bit_iterator_init(&it, required_fields, required_fields_sz, true);
> +	size_t id = bit_iterator_next(&it);
> +	if (id < SIZE_MAX) {
> +		/* A field is missing, report an error. */
> +		struct tuple_field *field =
> +			tuple_format_field_by_id(format, id);
> +		assert(field != NULL);
> +		diag_set(ClientError, ER_FIELD_MISSING,
> +			 tuple_field_path(field));
> +		return -1;
> +	}
> +	return 0;
> +}
> +
> +int
> +tuple_format_iterator_next(struct tuple_format_iterator *it,
> +			   struct tuple_format_iterator_entry *entry)
> +{
> +	entry->data = it->pos;
> +	struct mp_frame *frame = mp_stack_top(&it->stack);
> +	while (!mp_frame_advance(frame)) {
> +		/*
> +		 * If the elements of the current frame
> +		 * are over, pop this frame out of stack
> +		 * and climb one position in the format::fields
> +		 * tree to match the changed JSON path to the
> +		 * data in the tuple.
> +		 */
> +		mp_stack_pop(&it->stack);
> +		if (mp_stack_is_empty(&it->stack))
> +			goto eof;
> +		frame = mp_stack_top(&it->stack);
> +		it->parent = it->parent->parent;
> +	}
> +	entry->parent =
> +		it->parent != &it->format->fields.root ?
> +		json_tree_entry(it->parent, struct tuple_field, token) : NULL;
> +	/*
> +	 * Use the top frame of the stack and the
> +	 * current data offset to prepare the JSON token
> +	 * and perform subsequent format::fields lookup.
> +	 */
> +	struct json_token token;
> +	switch (frame->type) {
> +	case MP_ARRAY:
> +		token.type = JSON_TOKEN_NUM;
> +		token.num = frame->idx;
> +		break;
> +	case MP_MAP:
> +		if (mp_typeof(*it->pos) != MP_STR) {
> +			entry->data = it->pos;
> +			entry->field = NULL;
> +			mp_next(&it->pos);
> +			mp_next(&it->pos);

What about entry->data_end?

> +			return 0;
> +		}
> +		token.type = JSON_TOKEN_STR;
> +		token.str = mp_decode_str(&it->pos, (uint32_t *)&token.len);
> +		break;
> +	default:
> +		unreachable();
> +	}
> +	assert(it->parent != NULL);
> +	struct tuple_field *field =
> +		json_tree_lookup_entry(&it->format->fields, it->parent, &token,
> +				       struct tuple_field, token);
> +	if (it->flags & TUPLE_FORMAT_ITERATOR_KEY_PARTS_ONLY &&
> +	    field != NULL && !field->is_key_part)
> +		field = NULL;
> +	entry->field = field;
> +	entry->data = it->pos;
> +	/*
> +	 * If the current position of the data in tuple
> +	 * matches the container type (MP_MAP or MP_ARRAY)
> +	 * and the format::fields tree has such a record,
> +	 * prepare a new stack frame because it needs to
> +	 * be analyzed in the next iterations.
> +	 */
> +	enum mp_type type = mp_typeof(*it->pos);
> +	if ((type == MP_ARRAY || type == MP_MAP) &&
> +	    !mp_stack_is_full(&it->stack) && field != NULL) {
> +		uint32_t size = type == MP_ARRAY ?
> +				mp_decode_array(&it->pos) :
> +				mp_decode_map(&it->pos);
> +		entry->count = size;
> +		mp_stack_push(&it->stack, type, size);
> +		it->parent = &field->token;
> +	} else {
> +		entry->count = 0;
> +		mp_next(&it->pos);
> +	}
> +	entry->data_end = it->pos;
> +	if (field == NULL || (it->flags & TUPLE_FORMAT_ITERATOR_VALIDATE) == 0)
> +		return 0;
> +
> +	/*
> +	 * Check if field mp_type is compatible with type
> +	 * defined in format.
> +	 */
> +	bool is_nullable = tuple_field_is_nullable(field);
> +	if (!field_mp_type_is_compatible(field->type, mp_typeof(*entry->data),
> +					 is_nullable) != 0) {
> +		diag_set(ClientError, ER_FIELD_TYPE,
> +			 tuple_field_path(field),
> +			 field_type_strs[field->type]);
> +		return -1;
> +	}
> +	bit_clear(it->required_fields, field->id);
> +	return 0;
> +eof:
> +	if (it->flags & TUPLE_FORMAT_ITERATOR_VALIDATE &&
> +	    tuple_format_required_fields_validate(it->format,
> +			it->required_fields, it->required_fields_sz) != 0)
> +		return -1;
> +	entry->data = NULL;
> +	return 0;
> +}

  reply	other threads:[~2019-05-06 13:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 11:57 [PATCH v5 0/4] box: introduce multikey indexes in memtx Kirill Shcherbatov
2019-05-06 11:57 ` [PATCH v5 1/4] box: introduce tuple_format_iterator class Kirill Shcherbatov
2019-05-06 13:55   ` Vladimir Davydov [this message]
2019-05-06 14:32     ` [tarantool-patches] " Kirill Shcherbatov
2019-05-06 11:57 ` [PATCH v5 2/4] box: introduce field_map_builder class Kirill Shcherbatov
2019-05-06 14:22   ` Vladimir Davydov
2019-05-06 11:57 ` [PATCH v5 3/4] salad: introduce bps_tree_delete_identical routine Kirill Shcherbatov
2019-05-06 14:34   ` Vladimir Davydov
2019-05-06 14:55     ` [tarantool-patches] " Kirill Shcherbatov
2019-05-06 11:57 ` [PATCH v5 4/4] box: introduce multikey indexes in memtx Kirill Shcherbatov
2019-05-06 15:46   ` Vladimir Davydov
2019-05-06 16:35     ` [tarantool-patches] " Kirill Shcherbatov
2019-05-07  8:11       ` Vladimir Davydov
2019-05-07  8:28         ` Kirill Shcherbatov
2019-05-07 11:30           ` Vladimir Davydov
2019-05-07 13:13     ` Vladimir Davydov
2019-05-06 15:52 ` [PATCH v5 0/4] " Vladimir Davydov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190506135555.wgtewxgznfta3uss@esperanza \
    --to=vdavydov.dev@gmail.com \
    --cc=kshcherbatov@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='Re: [PATCH v5 1/4] box: introduce tuple_format_iterator class' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox