IH-577 Implement v7 UUID generation #5866
Conversation
rdn32
commented
Jul 19, 2024
rdn32
commented
- New function Uuidx.make_v7_uuid, with the idea being that ordering v7 UUIDs alphabetically will also order them by creation time
- The values produced by Uuidx.make_uuid_urnd hadn't necessarily been valid UUIDs, since the variant and version fields were being filled in randomly - this is now fixed so that it returns v4 UUIDs.
- There are a couple of functions for generating v4 and v7 from known inputs, for the purpose of unit testing. (The v4 function is mainly there so I could check the setting of variant and version fields by comparing the output with that which Python's UUID module produces.)
rdn32
force-pushed
the
private/rnewton/IH-577-uuidv7
branch
from
7b9e9f6
to
c5085e6
Compare
| val make_v7_uuid_from_time_and_bytes : int * int64 -> int64 -> 'a t | ||
| (** For testing only: create a v7 UUID, as defined in RFC 9562 5.7 *) | ||
|
|
||
| val make_v7_uuid : unit -> 'a t |
There was a problem hiding this comment.
Could this be changed to accept a function for the timestamp? That way we could use a monotonic clock source. The signature could be (unit -> uint64) -> 'a t
I know it would not be standard-compliant, and we would need to be careful about not persisting the produced timestamps, but I believe losing monotonicity here is something very undesired.
There was a problem hiding this comment.
I've gone for a hybrid approach whereby I use ptime to get the system time initially, then use mtime to get monotonic adjustments to that - so that we keep monotonicity but still have timestamps that are at least approximately correct.
rdn32
force-pushed
the
private/rnewton/IH-577-uuidv7
branch
2 times, most recently
from
f416ed4
to
037eef9
Compare
|
Is there a chance to upstream this code? We are using |
Because it's a new standard, it has leeway on how it can be implemented, and it needs to be as an additional package, I think there's a low chance to get into upstream. Having the suggestion upstream would maybe make its author to implement it |
|
It looks like generating a timestamp can't reasonably be done by uuidm (without introducing a dependency) but constructing v7 UUID given a timestamp could be. I can put together a PR. and see how well it goes down. |
The PR is dbuenzli/uuidm#14. Daniel Bünzli has added a '👍' reaction, which I take to be a good sign. |
|
He usually commits his own version of the change while referencing the original author |
rdn32
force-pushed
the
private/rnewton/IH-577-uuidv7
branch
from
037eef9
to
24a4f75
Compare
|
Please chime in on the PR to discuss this. I think it's a good idea to add basic support for v7 in uuidm. |
* New function Uuidx.make_v7_uuid, with the idea being that ordering v7 UUIDs alphabetically will also order them by creation time. The code that constructs a v7 UUIDs from a time and some random bytes has been submitted to uuidm and will be present in v0.9.9. * The values produced by Uuidx.make_uuid_urnd hadn't necessarily been valid UUIDs, since the variant and version fields were being filled in randomly - this is now fixed so that it returns v4 UUIDs as constructed by the uuidm module. * There is a function for generating v7 from known inputs, for the purpose of unit testing. Signed-off-by: Robin Newton <robin.newton@cloud.com>
rdn32
force-pushed
the
private/rnewton/IH-577-uuidv7
branch
from
24a4f75
to
bbb2135
Compare
|
I understand that v7 UUID will be implemented upstream as I suggested - which is great. Could you summarize what this PR achieves? |
The main thing it does is to give uuidx a wrapper for uuidm's new v7 UUID generation - including producing monotonic-yet-broadly-accurate timestamps. |
