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 v4 03/14] box: introduce tuple_field_by_relative_path
Date: Mon, 15 Oct 2018 20:46:33 +0300	[thread overview]
Message-ID: <20181015174633.s5r4ytfpzysqwese@esperanza> (raw)
In-Reply-To: <6d8609a936d992246e7dd7756151dc07eb92dea5.1539244271.git.kshcherbatov@tarantool.org>

On Thu, Oct 11, 2018 at 10:58:48AM +0300, Kirill Shcherbatov wrote:
> The new tuple_field_by_relative_path routine is used in function
> tuple_field_raw_by_path to retrieve data by JSON path from field.
> We need this routine exported in future to access data by JSON
> path specified in key_part.
> 
> Part of #1012.
> ---
>  src/box/tuple_format.c | 60 ++++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/src/box/tuple_format.c b/src/box/tuple_format.c
> index b385c0d..5679cad 100644
> --- a/src/box/tuple_format.c
> +++ b/src/box/tuple_format.c
> @@ -541,6 +541,42 @@ tuple_field_go_to_key(const char **field, const char *key, int len)
>  	return -1;
>  }
>  
> +/**
> + * Retrieve field data by JSON path.
> + * @param field Pointer to msgpack with data.
> + * @param path The path to process.
> + * @param path_len The length of the @path.
> + * @retval 0 On success.
> + * @retval >0 On path parsing error, invalid character position.
> + */
> +static inline int
> +tuple_field_by_relative_path(const char **field, const char *path,
> +			     uint32_t path_len)

I kinda dislike the function name. See, we have tuple_field_by_path,
which takes a tuple struct, and tuple_field_by_relative_path, which
takes raw msgpack. Please think of a better name so that everything
looks consistent.

Also, this function doesn't (and won't looking at the further patches)
look up tuple_field/offset_slot, which is another unsettiling difference
from tuple_field_by_path, despite similar names. May be, it should
descend the JSON tree as well?

> +{
> +	int rc;
> +	struct json_path_parser parser;
> +	struct json_path_node node;
> +	json_path_parser_create(&parser, path, path_len);

I don't like that you create a parser even if this function is called
from tuple_field_raw_by_path: you could pass the parser created by the
latter. I mean, you'd have two functions, one takes a relative path,
it's going to be public. Another takes a parser. The latter would be
called by the former and by tuple_field_raw_by_path.

> +	while ((rc = json_path_next(&parser, &node)) == 0) {
> +		switch (node.type) {
> +		case JSON_PATH_NUM:
> +			rc = tuple_field_go_to_index(field, node.num);
> +			break;
> +		case JSON_PATH_STR:
> +			rc = tuple_field_go_to_key(field, node.str, node.len);
> +			break;
> +		default:
> +			assert(node.type == JSON_PATH_END);
> +			return 0;
> +		}
> +		if (rc != 0) {
> +			*field = NULL;
> +			return 0;
> +		}
> +	}
> +	return rc;
> +}

  reply	other threads:[~2018-10-15 17:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11  7:58 [PATCH v4 00/14] box: indexes by JSON path Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 01/14] box: refactor key_def_find routine Kirill Shcherbatov
2018-10-15 17:27   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 10/14] box: introduce JSON indexes Kirill Shcherbatov
2018-10-16  9:33   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 11/14] box: introduce has_json_paths flag in templates Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 12/14] box: tune tuple_field_raw_by_path for indexed data Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 13/14] box: introduce offset slot cache in key_part Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 14/14] box: specify indexes in user-friendly form Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 02/14] box: introduce key_def_parts_are_sequential Kirill Shcherbatov
2018-10-15 17:29   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 03/14] box: introduce tuple_field_by_relative_path Kirill Shcherbatov
2018-10-15 17:46   ` Vladimir Davydov [this message]
2018-10-11  7:58 ` [PATCH v4 04/14] box: introduce tuple_format_add_key_part Kirill Shcherbatov
2018-10-15 19:39   ` Vladimir Davydov
2018-10-11  7:58 ` [tarantool-patches] [PATCH v4 05/14] box: introduce tuple_format_sizeof routine Kirill Shcherbatov
2018-10-15 17:52   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 06/14] box: move tuple_field_go_to_{index,key} definition Kirill Shcherbatov
2018-10-16  8:15   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 07/14] box: drop format const qualifier in *init_field_map Kirill Shcherbatov
2018-10-11  7:58 ` [PATCH v4 08/14] lib: implement JSON tree class for json library Kirill Shcherbatov
2018-10-16  8:26   ` Vladimir Davydov
2018-10-11  7:58 ` [PATCH v4 09/14] lib: introduce json_path_normalize routine Kirill Shcherbatov
2018-10-16  8:39   ` 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=20181015174633.s5r4ytfpzysqwese@esperanza \
    --to=vdavydov.dev@gmail.com \
    --cc=kshcherbatov@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='Re: [PATCH v4 03/14] box: introduce tuple_field_by_relative_path' \
    /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