[tarantool-patches] Re: [PATCH v1 1/1] rfc: describe a Tarantool JSON indexes

[Kirill Shcherbatov]

Actual link
https://github.com/tarantool/tarantool/blob/db468f172e642d3d830018a20e545eff77c655e3/doc/rfc/1012-json-indexes.md

> I still do not clearly understand what are you talking about. You can have
> different offsets in the same path: 1) [1][2][3].field and 2) [1][2][3]["field"].
> Here 'field' has offset 10 in the first case and 11 in the second
> one.
> 
> If you want to use prefix length in off.cache on comparison to walk the
> tuple_field trees along with the path in key_part on mismatch of cache
> versions, then you should explain more clear how do you want to use
> off.cache.
> 
> Lets suppose you have a key_part with a JSON path and a trees array.
> To determine into which tree you first go to find offset_slot, you
> should parse first path part. Same for each next part - you should
> parse it to go down the tree. So you just do not know into which
> tuple_field you go until the next part of the path is parsed. And how
> does tuple_field.off_cache help here?
> 
> And what will you do when you met a format which does not have
> an offset for the needed field? For example, I have created an
> index, inserted multiple tuples, then created another index. The
> format is changed, but the old tuples have the old format that
> does not have an offset to the parts of the new index.
You are right. This feature won't work.

> As I said, it is not special index tree. It can describe a space
> format with tens of fields among which only one is indexed.
> Index_tree is not correct name. It is tuple_field array as it is
> now, where each field is just a struct tuple_field. And struct
> tuple_field can contain more tuple_fields inside either as an array
> (if the field type is array) or inside a tree/hash if it is map.
Ok, fixed.