JOIN semantic for nested objects filtering

[Totktonada]

There are two approach to handle nested objects that are failed to fetch by a 1:1 connection:

• Give an error. This is the current behaviour. Seems to be GraphQL-way.
• Remove all parent objects while parent-child connections has 1:1 type (a first 1:N connected parent or top-level object will give the empty list). This is sort of backtraking and feels like SQL JOIN.

I don’t sure which option should be implemented (or both?).

[Totktonada]

Proposal for minimal implementation:

query get_orders_by_user_id($user_id: String) {
    order(user: {id: $user_id})
        id
        description
        user {
            id
            first_name
            last_name
        }
    }
}

• tarantool_graphql: add an argument for each 1:1 connection with its arguments as the type: type of the user argument above is the same as object_args for the order collection (which is destination collection for the user→order connection);
• accessor_general: detect 'user' field in the filter, fetch and unflat the user for each order (w/o any filters, by a connection, just call select_internal recursively), add the user for each order, pass the constructed object to is_subtable as before (it should support nested matching).

[Khatskevich]

An idea for optimization: if a condition is set on connection part, then it can be checked in the object itself.

[Khatskevich]

Proposal: Reuse executor for objects fetching

The idea of the proposal: it is not good to implement executor while we have one.

Implementation notes

In resolve function we can decide if a filter has constraints on inner objects, then it:

1. fetches its own object
2. creates callback, which is called by executor on the whole object when it's fetching is completed

Pros

1. do not implement the second executor
2. do not fetch objects two times
3. butching (ant other) optimizations should be implemented only once (in executor)

Cons

1. If we do not change executor much, then it will fetch only fields which are mentioned in inner query

user (order_connection:{price:3}) {
     user_id
     order_connection {
           description
     }
}

will not work, because we have condition on price, but we do not retrieve price
2. The same thing with conditions on nested objects which are not fetched at all

user (order_connection:{price:3}) {
     user_id
}

[Totktonada]

I’m going to implement the first approach (subrequests on the accessor_general level, no even caching) while we have no strong opinion how the future optimized executor will be implemented.

[Totktonada]

Note: The PoC implementation (see referencing commit above) does not follow the initial proposal in details. TBD: describe the approach of PoC.

[Totktonada]

Note: there was incomplete effort on the topic from Alex: 5935921.