Re: [Tarantool-patches] [PATCH 12/14] WIP: module api: expose box_key_def_merge()

[Alexander Turenko <alexander.turenko@tarantool.org>]

On Sat, Sep 26, 2020 at 12:58:21AM +0200, Vladislav Shpilevoy wrote:
> Thanks for the patch!
> 
> Why would a module need that function? Its usage case is very
> specific - merge primary and secondary parts to create a
> unique key def for non-unique indexes. Is there a case outside
> of the storage engines for that function?

Sure. At least I can give a case from merger usage: if we have several
sources of tuples that are sorted in the order of a secondary key +
primary key and want to merge them keeping the order, we need to
construct a key_def that is union of those key parts. The functions does
exactly this, that is very convenient.

Usage example:

https://github.com/Totktonada/tarantool-merger-examples/blob/557c15a191b465e8e9673203dd0e388a3345f625/chunked_example_fast/frontend.lua#L32-L36

Here we create a key_def object to pass it to merger as a tuple
comparator. The main function of this example, mr_call(), selects tuples
from given vshard cluster using given space, index and key (just like
usual box select).

If an index is not unique, we call :merge() to mix primary
key parts into secondary ones.

A predicatable order may be important in different tasks, but first
example that I have in the mind is pagination. It does not work, if the
order is not strictly defined (say, depend on how storages -- and so
merge source -- are enumerated when passed to merger).