*_object does not support sequences

[DifferentialOrange]

Plain tuples insert/replace/upsert works ok with sequence fields, but their *_object versions are not support them due to map flatten fail. We should consider if it is possible to improve flatten or describe that it is unsupported in doc.

[DifferentialOrange]

Customer example:

- null
- line: 207
  class_name: InsertError
  err: 'Failed to flatten object: FlattenError: Object is specified in bad format:
    FlattenError: Field "unitID" isn''t nullable'
  file: '...lov/bms/tarantool/.rocks/share/tarantool/crud/insert.lua'
  str: 'InsertError: Failed to flatten object: FlattenError: Object is specified in
    bad format: FlattenError: Field "unitID" isn''t nullable'

[R-omk]

Perhaps first it need to decide in principle how sequences and vshard could work together.
The fact is that native sequences cannot be sharded.

[DifferentialOrange]

Perhaps first it need to decide in principle how sequences and vshard could work together. The fact is that native sequences cannot be sharded.

Yeah, I've planned to add a warning near implementation about vshard+sequences. I suppose that the customer which had issued this used crud over single-shard replicaset vshard group.

[DifferentialOrange]

See also tarantool/tarantool#7858

[DifferentialOrange]

In result, the issue is more tricky than it seems.

Solution 1: allow to pass null values for fields with sequence index

The idea seems nice and it is the first one which comes to mind. But there is no way to know that field value is provided by sequence: net.box do not carry any info, see tarantool/tarantool#7858. So to implement this, we must first extract sequence info.

The only way to actually check if the space use sequence is a network call. Moreover, even if tarantool/tarantool#7858 would be solved, it won't be supported by older releases.

Network call info needs to be cached since extra network call for each object operation would ruin the performance. On the other hand, it is rather hard to implement fair and square cache for sequence data since it should

• be conscious of space schema reload (which could be implemented with net.box connection triggers),
• be conscious of package hot reload and Cartridge roles hot reload (which can be neglected for cache itself but cannot be neglected for triggers from the previous point),
• do not depend on replicasets instance since crud may choose any master instance to extract the format for flatten (which contradicts the first point).

I also don't see any way to use the assumption that sequence can be used only for primary index since it is possible to drop primary index on the runtime.

Solution 2: allow to pass the flag to ignore nullability check on flatten

This solution seems more inconvenient for a user since now they should be conscious about whether they want to check nullability or not. They also lose the ability to fast-fail on missing non-nullable field if they use the sequence but haven't filled any non-sequence field in tuple.

On the other hand, this one seems much simple to implement since it shouldn't be conscious of schema reload. And since the user request about vshard + sequence is rather exotic in nature and won't be used by 99% of module users, I think it would be ok to make the 1% to explicitly set a flag, especially since it is better to explicitly remind them in the flag description that vshard + sequence should also be processed on their side.

Solution 2.1

Pass the flag with each request.

Solution 2.2

Use our nice little crud.cfg.