[tarantool-patches] Re: [PATCH v1 1/1] rfc: describe a Tarantool JSON indexes
- From: Kirill Shcherbatov <kshcherbatov@xxxxxxxxxxxxx>
- To: tarantool-patches@xxxxxxxxxxxxx, Vladislav Shpilevoy <v.shpilevoy@xxxxxxxxxxxxx>, Vladimir Davydov <vdavydov.dev@xxxxxxxxx>
- Date: Mon, 30 Jul 2018 22:23:40 +0300
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.
Other related posts:
