Write tests for a nullable index on shard

[Totktonada]

We should correctly handle nullable index with partial/full keys. Cases TBD.

[Totktonada]

We should support filtering features capacity like SQL does. For plain selects (w/o connections): IS NULL / IS NOT NULL. I think it must be implemented via future 'filter' argument (added to and tracked by #13).

For 1:1 connections we should choose one of MATCH SIMPLE / MATCH PARTIAL / MATCH FULL behaviour (from SQL, part of the REFERENCES clause). The same / an another behaviour should be choosen for 1:N connections.

MATCH behaviourr in terms of connections:

• MATCH SIMPLE: connection is considered as orphan (null) if any of key parts (in a source object) is null. Otherwise it must point to an existing tuple in the parent table.
• MATCH PARTIAL: connection considered as orphan (null) if all key parts (in a source object) are null. Otherwise it must point to at least one tuple in the parent table. If some keys are null and some are not, then the connection match those tuples of the parent table that have matched non-null parts (and any values for null parts of the key).
• MATCH FULL: connection considered as orphan (null) if all key parts (in a source object) are null. If all key parts are non-null then the corresponding tuple must match the key. Otherwise (non-zero count of non-null key parts, but less than all) the state is not consistent.

My proposal is to use MATCH FULL behaviour (because it is the most strict one) for both 1:1 and 1:N connections at least before we’ll find real cases where less strict constraints are helpful.

Offset is always by a primary index (UNIQUE and NOT NULL), so it is non-sense to pass null as a part of such key. As result offset parts must be non-null. (It is validated by comparing parts count.)

Before going to test cases we should split the problem into the two parts.

1. Nullable connections. There must be an option within a connection to mark it nullable. GraphQL schema must allow to omit the connection field in case of a nullable connection. When the source set of fields forms a null key (by MATCH FULL) we don’t need to fetch any object from a destination collection.

Note: the connection underlying index (within the destination collection) can be nullable or not, it does not matter. But within the MATCH FULL logic we cannot fetch by the connection those destinations objects have nulls in the corresponding fields (because we either don’t have not nulls in the key or don’t fetch the destination collection objects). I think we should not ban such kind of indexes, because the indexes can be reused for other reasons.

2. Nullable indexes. We should make sure that fetching objects by a nullable indexes works as expected (does not matter over spaces or shard).

There are three cases that can lead to use an index:

a) fetching top-level objects by a list of non-null values (we should make sure that null cannot be passed explicitly, though);
b) use offset by a top-level object, the case looks the save as a).
c) lookup by a connection by a key with all non-null values (due to MATCH FULL semantic).

The question is:

Q) Can we pass a key with nullable parts explicitly or implicitly (via a connection)? The answer is 'no' (at least until we’ll add support for IS NULL / IS NOT NULL).

The fullscan case and GT iterator case does not matter, because we do fullscan only by a primary key. So, we should check that nullable indexes works as expected with a non-null key for EQ iterators (don’t show nulls in the corresponding fields).

The indexes to check are: compound secondary unique/non-unique matching with a key as full/partial with at least one nullable part; the data should contain at least two objects with nulls in the field corresponding the nullable index part.

Cases to test nullable indexes on spaces and shard (and compare results):

• verify that null as an argument value (or value part) is forbidden;
• top-level objects: full secondary index (scalar index is okay);
• connection: partial match with compound secondary index (two cases: nullable part within a key or not).