-
-
Notifications
You must be signed in to change notification settings - Fork 126
Open
Description
❗ This issue is a work in progress, I'll do a bit more research into the implementation details.
Motivation:
- Prefixed IDs allow for the identification of the model with which the ID acts as a primary key for
- The Stripe team has published a great article on the benefits of this: https://dev.to/stripe/designing-apis-for-humans-object-ids-3o5a
- TLDR:
- Quickly allows for the identification of potential bugs
- Better aids readability & observability
- A point that was omitted from the article: allows for the use of templated literal types in TS, such as
prefix_${string}- which greatly increases type-safety, as casting an ID to simplystringcan be a massive source of bugs in large projects
Technical implementation:
- Still looking into this, will update later on, but for now:
- Looks like it will have to be implemented via a small custom plugin in the DB
- If wanting to avoid the plugin, then this might work?
Postgres:
CREATE TABLE users (
id VARCHAR(50) PRIMARY KEY DEFAULT 'user_' || REPLACE(gen_random_uuid()::text, '-', ''),
name VARCHAR(100)
);
MySQL:
CREATE TABLE users (
id VARCHAR(50) PRIMARY KEY DEFAULT CONCAT('user_', REPLACE(UUID(), '-', '')),
name VARCHAR(100)
);Application vs DB Layer:
- Stripe mentions in their blog post that they implement this prefixing at the DB layer, as opposed to the application layer
- This helps when having to inspect ids that don't originate from the app layer, e.g. data dumps, direct DB queries etc. - at the cost of a slightly larger DB
eraoul, ymc9 and daaain
Metadata
Metadata
Assignees
Labels
No labels