[Uid] Add UuidV1::toV6(), UuidV1::toV7() and UuidV6::toV7()
#53060
Conversation
9f642f1 to
8471425
Compare
UuidV6::fromV1() and UuidV7::fromV1() methodsUuidV1::toV6(), UuidV1::toV7() and UuidV6::toV7()
b4cfc82 to
0d64a55
Compare
There was a problem hiding this comment.
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? 🤔
0d64a55 to
7ac5d9d
Compare
It doesn't cost much to provide v6 to v7 so why skip it? |
7ac5d9d to
9ee1437
Compare
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. |
|
Thank you @fancyweb. |
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 😅