ddl.get_schema must return field name in index parts

[akudiyar]

Currently there is no way to easily determine the field number or the field name from the returned "path" field: either a sophisticated logic is needed (splitting the value by dot, etc) or it is completely impossible for multikey indexes.

This is needed for connectors (e.g. cartridge-java).

[rosik]

But index part ~= field. Sometimes they may coincide, but in general, they don't. That's how tarantool works.

[Totktonada]

It would be easier to discuss it with examples and user scenarious.

Let's assume we have a space with the following format:

{
    {name = 'id', type = 'string', is_nullable = false},
    {name = 'full_name', type = 'string', is_nullable = true},
    {name = 'email', type = 'string', is_nullable = true},
}

And the following secondary index:

{
    type = 'TREE',
    name = 'middle_name',
    unique = false,
    parts = {
        {path = 'full_name.middle_name', type = 'string', is_nullable = true, collation = nil},
    },
}

The index 'middle_name' uses a piece of 'full_name' field information. What kind of task requires information from which field this piece of information is originated? Feel free to show it on another example. I want to understand a user scenario here.

[akudiyar]

Matching between index fields and field positions is necessary for making correct box API requests with index values from an entity through a connector.

Let's consider the entity in your example. When you are writing an index query, you'll use something like

box.space.user.index.secondary:select(my_user.full_name.middle_name
) -- "Ivanovich"

But when we are using connectors, often we have an entity backed by a tuple and we need to guess which field of it we need to pick for putting as the value for this query. And furthermore, if we are trying to determine the best index for querying something according to the user's request, we need to match several indexes and pick up the narrower one. There we start calculating the longest index value tuple -- you can see an example in cartridge-java (look at the Conditions.java class). And for making these index value tuples we need to match a position in an index to a tuple field.

[Totktonada]

We discussed it with Alexey voicely. I'd like to summarize how I understood the problem.

Context: a client side ORM needs full schema data to implement pagination. A pagination requires key extraction from a tuple, including key parts that corresponds to an index key part defined by a JSON path.

The problem is that it is unclear, how exactly interpret JSON path key part definition. The solution would be a clear description of the algorithm and, if needed, changes in tarantool or tarantool/ddl to define it.

What is not clear:

1. JSON path index allows to set a path starting from root of a tuple (including a field name) or starting from a field (excluding a field name). Whether tarantool normalizes both forms into one? Whether tarantool/ddl does?
2. Whether field name is always defined or missed if the path field contains it (on tarantool level and on tarantool/ddl level)?