[Tarantool-patches] [PATCH] key_def: support composite types extraction

[Alexander Turenko]

> >How about lbox_key_def_merge() and underlying functions? I'm not sure
> >they will work correct. At least I tried this on the branch:
> >
> > | tarantool> key_def = require('key_def')
> > | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'array'}})
> > | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'map'}})
> > | tarantool> kd1:merge(kd2)
> > | ---
> > | - - type: array
> > | is_nullable: false
> > | fieldno: 1
> > | ...
> >
> >It does not look correct.
> This turns out to be the correct behavior:
>  
> tarantool> kd1 = key_def.new({{fieldno = 1, type = 'unsigned'}})
> ---
> ...
> tarantool> kd2 = key_def.new({{fieldno = 1, type = 'string'}})
> ---
> ...
> tarantool> kd1:merge(kd2)
> ---
> - - type: unsigned
>     is_nullable: false
>     fieldno: 1
> …

I'm not sure it is correct. But at least you proved that it is not in
the scope of your current task :)

An attempt to create conflicting indices gives an error, so I guess this
case is not handled, because it was not possible until we exposed
key_def directly to Lua.

But another case makes me doubt even more:

 | tarantool> key_def = require('key_def')
 | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'scalar'}})
 | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'integer'}})
 | tarantool> kd1:merge(kd2)
 | ---
 | - - type: scalar
 |     is_nullable: false
 |     fieldno: 1
 | ...
 |
 | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'integer'}})
 | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'scalar'}})
 | tarantool> kd1:merge(kd2)
 | ---
 | - - type: integer
 |     is_nullable: false
 |     fieldno: 1
 | ...

It would be natural to get most restricted type, when one type is subset
of another. I assume the following invariant: for any given kd1 and kd2
kd1:merge(kd2) should accept only those tuples that both kd1 and kd2
accept (kd accepts a tuple when it is valid against kd).

OTOH, the main use case for :merge() function is to compare tuples in
the same way as a non-unique secondary index do (when a key parts of a
primary index are implicitly merged into the secondary index ones). In
this sense we can choose either subtype or supertype: it will not affect
an order of tuples. So choosing of the first (secondary index's) key
part looks okay.

I don't know whether we should change anything or not, so just shared my
findings and thoughts.

If I'll somehow end with an idea that we should do something here, I'll
file an issue.

WBR, Alexander Turenko.