Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
[Uid] AddUuidV1::toV6(),UuidV1::toV7() andUuidV6::toV7()#53060
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Uh oh!
There was an error while loading.Please reload this page.
9f642f1 to8471425CompareUuidV6::fromV1() andUuidV7::fromV1() methodsUuidV1::toV6(),UuidV1::toV7() andUuidV6::toV7()
nicolas-grekas left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thanks for pushing this :)
I added a second commit where I renamedfrom*() methods toto*()
and I made the resulting UUIDv7 monotonic within the same 100-ns (modulo the clock-seq)
b4cfc82 to0d64a55Compare
fancyweb left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Thank you very much for looking at this Nicolas 🐐
It looks like we are close to the perfect solution thanks to you. However, after reviewing it and testing it I've found that the xor doesn't always produce valid UUIDs (see failing test).
Also, what do you think of going directly from v1 to v7 to avoid the unneeded v6 step? I'm actually not even sure v6 -> v7 is needed at all since they are part of the same RFC iteration: I don't see any case where a system would be able to generate v6 but not v7 directly? 🤔
Uh oh!
There was an error while loading.Please reload this page.
0d64a55 to7ac5d9dComparenicolas-grekas commentedDec 21, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
It doesn't cost much to provide v6 to v7 so why skip it? |
7ac5d9d to9ee1437Comparefancyweb commentedDec 21, 2023
Because nobody will use it 😅 I reviewed it again and it's OK for me. I can't approve it since it's my own PR. I force-pushed again to add more assertions. |
nicolas-grekas commentedDec 26, 2023
Thank you@fancyweb. |
Uh oh!
There was an error while loading.Please reload this page.
The goal is to help working with new UUIDv6 & v7 versions when you receive legacy UUIDv1.
UUIDv6 and v1 are 100% compatible since v6 is just a "reordering" of v1.
UUIDv7 and v1 are not strictly compatible for several reasons: the timestamp precision is not the same. Also, there is no clock seq or variant or node in v7 but full randomness instead. And maybe others?
However, I believe we can still technically do the conversion (timestamp -> timestamp, clock seq + variant + node -> randomness) with at least one concession: the sub-milliseconds v1 timestamp precision is lost since v7 doesn't support it.
My proposed v1 to v7 implementation has 2 issues:
I'm opening this PR so that@nicolas-grekas gets triggered by the inefficiency of my code and finds a better solution 😁
I'm kidding, I actually know he already has an idea because he explained it to me during the Brussels HackDay but I couldn't understand it well enough to be able to implement it 😅