-
-
Notifications
You must be signed in to change notification settings - Fork 907
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support new IETF UUID formats #580
Comments
Good issue. I'm generally in favor of this, as the new versions have some much-needed improvements over the original spec. However, this spec appears to still be an early, unadopted draft (e.g. numerous typos, not yet assigned an RFC #). Until this is more formally adopted by the IETF, I don't think it's appropriate for us to officially support it. (That's not to say we couldn't publish an "experimental" branch / release, but I don't see that as a high priority task.) |
The new UUID formats are being discussed in this github repo: https://github.com/uuid6/uuid6-ietf-draft |
I've just created an isomorphic implementation for the current UUIDv7 draft: https://github.com/kripod/uuidv7 – I would appreciate some feedback about it. |
@kripod in your example how does one provide the node id in a distributed context? Also I was wondering if we can provide a custom clock source. In case we wanted a monotonic clock. |
@CMCDragonkai providing a custom machine ID isn’t possible yet, but 62 random bits should be sufficient to avoid collisions. Does the spec draft mention how to use machine IDs within a UUIDv7? Not sure if a custom clock source may ever be provided, as JS is single-threaded and thus, Please open new issues about these over here. |
Based on @kripod work and some discussions in the upstream spec and the prototype code here https://github.com/uuid6/prototypes, we've developed js-id https://github.com/MatrixAI/js-id for use in our company's projects. The |
Marking as stale due to 90 days with no activity. |
Closing issue due to 30 days since being marked as stale. |
Quick update: The new versions are being spec'ed out by the UUID revision Working Group based on the draft work mentioned previously. There doesn't seem to be a lot of concern or contention so far, which has me thinking we could start add support for these new formats... maybe under an "experimental" release version of some sort without too much risk of major changes being needed. |
note, husky pre-commit hook was bypassed for this commit
Tracking support for RFC4122bis here: https://github.com/orgs/uuidjs/projects/1 |
* feat: implement uuid7 (uuidjs#580) * fix: add v7.js to .local (uuidjs#580) note, husky pre-commit hook was bypassed for this commit * fix: add v7 to uuid-bin * chore: fix readme anchor * chore: use generated readme, remove timestamp arg from uuid-bin v7 * fix: typo in uuid regex, add negative test cases * fix: do not mutate provided rnds, add v7 unit tests * fix: validation test should not pass version 0 * chore: update package.json description * Update src/v7.js Co-authored-by: Linus Unnebäck <linus@folkdatorn.se> * include uuid v6 and v8 in validation regex * chore: add test:matching script to package.json * fix: v7 monotonicity and lexicographical sorting * refactor: v7 seq reinitialization * chore: update v7 README --------- Co-authored-by: Patrick McCarren <patrick@cumulative.io> Co-authored-by: Linus Unnebäck <linus@folkdatorn.se>
Marking as stale due to 90 days with no activity. |
I just came across this article, and I'd really like to start using UUIDv7. It looks like the code in csmith23#1 was solid (please someone more qualified audit the generator, but the test coverage and updates to documentation looked great) but I don't see a PR into this repo. Edit: I now found the discussion continued in: #681 |
If I'm going to start a new project, is it a bad idea to use v1 only temporarily while waiting for v7 experimental or not? so that I structure my identifiers as Postgres uuid and have lexicographic sorting |
@Crsk I think, trying to hurry up the implementation doesn't add to the conversation. Also, there are multiple Postgres add-ons: |
You all probably already know, but just in case, RFC 9562 was published a few days ago (May 7, 2024). https://www.rfc-editor.org/rfc/rfc9562 |
Now tracking this in #749 |
A recently published draft RFC proposes three new time-based UUID formats. The UUIDv1 is also time-based, but the timestamp is formatted little-endian, whereas the new formats use a big-endian format. This means the UUID's will naturally sort in order of time, which has several engineering advantages.
Because the RFC is still a draft, I wouldn't yet expect that UUID libraries can generate the new formats. I'd like to know if this library intends to implement them, however.
I thought it would be useful to create this issue, so we can see if:
https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-01
The text was updated successfully, but these errors were encountered: