You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2022. It is now read-only.
Is your feature request related to a problem? Please describe.
At the moment, primary keys in the database are generated by Postgres as integers and auto incremented.
This has the following disadvantages:
it is not possible to anticipate the id of a category, item or mod until it is actually created.
ids in the database are integers, while ids in GraphQL are strings. This forces us to implement type casting in both ways.
Describe the solution you'd like
As a software developer I want to manage data with deterministic uuids So that we can have a more resilient, interoperable backend with support for offline operations
To change the datatype for all primary keys from integer to the native UUID type offered by Postgres.
To include those ids in all GraphQL in input types, and them client generated, as universally unique identifiers.
Cost of not doing
We would be missing the following advantages:
less impedance mismatch between GraphQL and Postgres.
easier data migration between systems
resiliency and idempotency
offline operations, where the database is not available
How we may solve this
From a technical point of view, this would involve:
Migrate existing tests
Update existing GraphQL input types
Adapt Ecto Schemas
Implement migrations on all tables
Since this is a potentially big feature, we could approach this by contexts:
Is your feature request related to a problem? Please describe.
At the moment, primary keys in the database are generated by Postgres as integers and auto incremented.
This has the following disadvantages:
Describe the solution you'd like
As a software developer
I want to manage data with deterministic uuids
So that we can have a more resilient, interoperable backend with support for offline operations
Cost of not doing
We would be missing the following advantages:
How we may solve this
From a technical point of view, this would involve:
Since this is a potentially big feature, we could approach this by contexts:
Additional context
The text was updated successfully, but these errors were encountered: