Whether it worth to deduce connection type (1:1 or 1:N) from index parts provided

[Totktonada]

The proposal was to consiner:

• full primary index lookup as unique,
• partial primary index lookup as non-uniue,
• full/partial secondary index as non-unique.

I don’t sure we want to reduce flexibility here, like use the unique secondary index as an uniue one. From the other side, for space/shard accessors that affects only result shape: get an object or list of one item which is that object. Need to elaborate how that really constraint us in possible accessor implementations.

The original decision to move indexes description from the graphql part was inspired by feeling that it looks more like accessor’ part, then graphql’s one. But there is possible compromise: link a connection with an index in data accessor, then fetch connection types information in graphql part from the accessor.

[Totktonada]

@SudoBobo Can you please check whether it was done in the scope of #59 and #60?

[Totktonada]

It also should be done as part of #41.

[Totktonada]

I'm going to archive the repository. I'll proceed as follows:

• Mark all open pull requests with the archived label and close.
• Mark all open issues with archived and wontfix labels and close.
• Archive the repository.

Consider the following projects:

• https://github.com/tarantool/graphql
• https://github.com/tarantool/graphqlapi
• https://github.com/tarantool/graphqlide