Skip to content
This repository has been archived by the owner on Apr 2, 2024. It is now read-only.

Commit

Permalink
Update README.md for deprecation
Browse files Browse the repository at this point in the history
+drafting the original idea
  • Loading branch information
ebln committed Apr 2, 2024
1 parent 2b2b180 commit 2747515
Showing 1 changed file with 18 additions and 0 deletions.
18 changes: 18 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,21 @@
# DEPRECATED

With the advent of [UUID Version 8](https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis-00#section-5.8) better use a regular UUID library and reimplement.

- With the first 16 bit of `custom_a` to specify a domain, model or table
- The `ID` taking up 64 bits from `custom_c` and the last 2 bits of `custom_b`
- While optional, the original idea was:
- 4 bit for type, directly following the domain block in `custom_a`
- coding types
- «neutral» implying no special semantics for the free bits between domain and id (0)
- «sortable» a monotonic increment, meant for legacy data without recoverable timestamps (1)
- «timestamp» timestamp with an offset to the epoch (32 bit, filled up with all free bits; 2)
- «sharding» all bits in the middle would make up an instance id for sharding
- The `ID`s were supposed to be obfuscatable using [Knuth's integer hash of jenssegers/optimus](https://github.com/jenssegers/optimus)
- This all was meant to be a gentle path for migrating autoincremented row IDs to UUIDs, while making it possible to programatically extract the original table (mapped as domain id) and the original row id from the UUID.


----
Namespaced IDs via UUID
=======================

Expand Down

0 comments on commit 2747515

Please sign in to comment.