From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 16 Apr 2018 11:35:49 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH v3 3/3] Lua: implement json path access to tuple fields Message-ID: <20180416083549.uyiayz3kcqfgd6kt@esperanza> References: <20180413113326.3lijwwzy6dwzrgev@esperanza> <48a37669-c959-1f31-1bee-ecd85787046f@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <48a37669-c959-1f31-1bee-ecd85787046f@tarantool.org> To: Vladislav Shpilevoy Cc: tarantool-patches@freelists.org, kshcherbatov@tarantool.org List-ID: On Sat, Apr 14, 2018 at 12:51:30AM +0300, Vladislav Shpilevoy wrote: > Hello. Thanks for review. > > New commit message: > > lua: implement json path access to tuple fields > > Until this moment in Lua a tuple data could be accessed in 3 ways: > - get field by field number, decode into Lua, > - get field by field name, decode into Lua > - decode entire tuple into Lua. > > It was impossible to decode into Lua only a part of the field to > avoid Lua garbage creating. For example, consider the tuple: > `{1, 2, {key1 = value1, > key2 = {key21 = {key211 = {key2111, key2112}}}}}` > with field names `field1`, `field2`, `field3`. > > To get `key2112` it is necessary to decode into Lua the entire > 3-th field, including `key1`, `value1`, `key2`, `key21`, > `key211`, `key2111` using the syntax > `key2112 = tuple.field3.key2.key21.key211[2]`. > > Now the one can use the following syntax: > `key2112 = tuple["field3.key2.key21.key211[2]"]`. The difference > is in placing all the path into quotes and brackets `["..."]`. > The Tarantool goes through this path and MessagePack tuple body, > gets the needed tuple part and decodes into Lua only it. > > The path must be valid JSON path with one exception - in > Tarantool a path can start with `.`. For example: > `tuple[".field3..."]` - it is done to lay emphasis that the JSON > path here is just a suffix for the tuple. > > At the same time tuple field names still work: `tuple["field1"]`, > `tuple.field2`. > > If the field name looks like JSON path, for example: > `my.field.name`, then it works too. The path at first is checked > to be a real JSON path, and if nothing is found, then the entire > path is considered as a field name. To combine such names and > path elements the one can use `["..."]`. For example: > `tuple["['my.field.name'].key1.key2.['another.key.in.map']"]`. > > Closes #1285 > > > > > Why did you move handling of integer index from Lua to C? AFAIU having > > it in Lua should be faster. Besides, this new function is kinda > > difficult to follow IMO as it does two things now. I'd prefer it to do > > just one thing - looking up a tuple field by path. > > > > Fixed. I returned the tuple field by number implementation as it > was before JSON path patch. Thanks. The patch looks good to me now. There's one thing: the hunk below doesn't belong to this patch. Obviously, it should be a part of the previous patch. Please move it there before pushing it to the trunk. diff --git a/test/unit/json_path.result b/test/unit/json_path.result index 9b4ea641..a2a2f829 100644 --- a/test/unit/json_path.result +++ b/test/unit/json_path.result @@ -1,7 +1,7 @@ *** main *** 1..2 *** test_basic *** - 1..67 + 1..71 ok 1 - parse <[0]> ok 2 - <[0]> is num ok 3 - <[0]> is 0 @@ -46,29 +46,33 @@ ok 42 - is str ok 43 - len is 6 ok 44 - str is field1 - ok 45 - parse <[1234]> - ok 46 - <[1234]> is num - ok 47 - <[1234]> is 1234 - ok 48 - parse empty path - ok 49 - is str - ok 50 - parse - ok 51 - is str - ok 52 - len is 6 - ok 53 - str is field1 - ok 54 - parse <[2]> - ok 55 - <[2]> is num - ok 56 - <[2]> is 2 - ok 57 - parse <[6]> - ok 58 - <[6]> is num - ok 59 - <[6]> is 6 - ok 60 - parse <привет中国world> - ok 61 - <привет中国world> is str - ok 62 - len is 23 - ok 63 - str is привет中国world - ok 64 - parse <中国a> - ok 65 - <中国a> is str - ok 66 - len is 7 - ok 67 - str is 中国a + ok 45 - parse + ok 46 - is str + ok 47 - len is 6 + ok 48 - str is field1 + ok 49 - parse <[1234]> + ok 50 - <[1234]> is num + ok 51 - <[1234]> is 1234 + ok 52 - parse empty path + ok 53 - is str + ok 54 - parse + ok 55 - is str + ok 56 - len is 6 + ok 57 - str is field1 + ok 58 - parse <[2]> + ok 59 - <[2]> is num + ok 60 - <[2]> is 2 + ok 61 - parse <[6]> + ok 62 - <[6]> is num + ok 63 - <[6]> is 6 + ok 64 - parse <привет中国world> + ok 65 - <привет中国world> is str + ok 66 - len is 23 + ok 67 - str is привет中国world + ok 68 - parse <中国a> + ok 69 - <中国a> is str + ok 70 - len is 7 + ok 71 - str is 中国a ok 1 - subtests *** test_basic: done *** *** test_errors ***