<HTML><BODY><div><div>Right, I agree with the thoughts on the compatibility.</div><div>I think this might be a thing to ask solutions?</div><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">Четверг, 1 октября 2020, 14:38 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>:<br> <div id=""><div class="js-helper js-readmsg-msg"><style type="text/css"></style><div><div id="style_16015522970149744718_BODY">> >How about lbox_key_def_merge() and underlying functions? I'm not sure<div class="mail-quote-collapse">> >they will work correct. At least I tried this on the branch:<br>> ><br>> > | tarantool> key_def = require('key_def')<br>> > | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'array'}})<br>> > | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'map'}})<br>> > | tarantool> kd1:merge(kd2)<br>> > | ---<br>> > | - - type: array<br>> > | is_nullable: false<br>> > | fieldno: 1<br>> > | ...<br>> ><br>> >It does not look correct.<br>> This turns out to be the correct behavior:<br>> <br>> tarantool> kd1 = key_def.new({{fieldno = 1, type = 'unsigned'}})<br>> ---<br>> ...<br>> tarantool> kd2 = key_def.new({{fieldno = 1, type = 'string'}})<br>> ---<br>> ...<br>> tarantool> kd1:merge(kd2)<br>> ---<br>> - - type: unsigned<br>> is_nullable: false<br>> fieldno: 1<br>> …</div><br>I'm not sure it is correct. But at least you proved that it is not in<br>the scope of your current task :)<br><br>An attempt to create conflicting indices gives an error, so I guess this<br>case is not handled, because it was not possible until we exposed<br>key_def directly to Lua.<br><br>But another case makes me doubt even more:<br><br> | tarantool> key_def = require('key_def')<br> | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'scalar'}})<br> | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'integer'}})<br> | tarantool> kd1:merge(kd2)<br> | ---<br> | - - type: scalar<br> | is_nullable: false<br> | fieldno: 1<br> | ...<br> |<br> | tarantool> kd1 = key_def.new({{fieldno = 1, type = 'integer'}})<br> | tarantool> kd2 = key_def.new({{fieldno = 1, type = 'scalar'}})<br> | tarantool> kd1:merge(kd2)<br> | ---<br> | - - type: integer<br> | is_nullable: false<br> | fieldno: 1<br> | ...<br><br>It would be natural to get most restricted type, when one type is subset<br>of another. I assume the following invariant: for any given kd1 and kd2<br>kd1:merge(kd2) should accept only those tuples that both kd1 and kd2<br>accept (kd accepts a tuple when it is valid against kd).<br><br>OTOH, the main use case for :merge() function is to compare tuples in<br>the same way as a non-unique secondary index do (when a key parts of a<br>primary index are implicitly merged into the secondary index ones). In<br>this sense we can choose either subtype or supertype: it will not affect<br>an order of tuples. So choosing of the first (secondary index's) key<br>part looks okay.<br><br>I don't know whether we should change anything or not, so just shared my<br>findings and thoughts.<br><br>If I'll somehow end with an idea that we should do something here, I'll<br>file an issue.<br><br>WBR, Alexander Turenko.</div></div></div></div></blockquote> <div> </div><div data-signature-widget="container"><div data-signature-widget="content"><div>--<br>Ilya Kosarev</div></div></div><div> </div></div></BODY></HTML>