id for client usages

[ivansglazunov]

Recreated from discord room.

@ivansglazunov Now every id = bigint. This prevents the creation from client some random id created before the insert operation. Are we going to add separate columns for such string ids (as in shakeapp? Any other ideas?
@konard If GraphQL starts to support @export feature (graphql/graphql-spec#583, https://blog.logrocket.com/creating-an-export-graphql-directive/) it will be possible to create any number of nodes without the need for random ids.
We can also make a mutation that books (reserves) a number of ids from the bigint range, it should be also possible to free reserved batch of ids. Reservations of 50-100 ids and so on should have a timeout. For example reservation of any number of ids can be done for one hour. After this hour is passed away reserved ids are automatically made available for other clients. So only thing the client should do is to have enough reserved ids for each request, and if in extreme case the client is run out of ids it can request it just in time (before the insert mutation is done). In all other cases the client will preserve 50-100 ids for all the time the client is active.
This will not require to wait for change in the GraphQL spec.
We can also create string ids that are stored inside the DB as a secondary ID.
And it will be always possible to request primary id (bigint), by the secondary ID.
May be there is a way to use temporary relative ids (ids relative to request, for example negative ids).
As I understand the main reason for random ids is to be able to do bulk insert. Is this correct?

[ivansglazunov]

@konard

As I understand the main reason for random ids is to be able to do bulk insert. Is this correct?

No. Main reason - create id on client, apply changes to ui (as switch page to id of item) without waiting mutation. It classic practice in ui optimization.

[konard]

So the main requirement is to do no wait for the database response?

[ivansglazunov]

Yes.

[ivansglazunov]

I see now two solutions:

• string ids tables for client reasons, just easy
• precalculated numeric ids range for each client session, create something line precalculatedIdsRangeManager role, hurt solution, big chance to unexpected conflicts

[ivansglazunov]

After meeting with @konard.

• For example 7 is type ReservedLink
• Client can call gql reserve(count: 5) for define reserved links. It create 5 links { id: N, from: UserLink, to: ClientLink, type: ReservedLink } with predefined ids.
  • If client insert new link with id from predefined links, then instead of insert update reserved link to sended, or create new link.
• Not part of main deepcase/deepgraph. Separated package for client reserved ids with instead of insert function and reserved mutation.