-
Notifications
You must be signed in to change notification settings - Fork 11
Have just one new UUID version rather than three(?) #30
Comments
For now, the best practice is to use v4 in the generic cases, and use v5 in those rare cases when a reproducible identifier is required.
Definitely
Agree |
Providing some history of the drafts:
Edit: fixed unclosed quotes |
I understand. This is the reason why issue #29 was created
I believe, RFC should describe best practices, not all possible ways. Of course, this is just an opinion. I cannot insist. |
@kyzer-davis Thanks for the backstory. That's helpful.
First of all, the number of folks doing this is a minute fraction of the eventual audience this spec will impact. RFCs should be inspired by existing work, but they should be designed for the audience they will eventually impact. If there are flaws in the prior art that inform an RFC, those flaws should be addressed by the RFC... and I believe there are real flaws here. Specifically, these folks that are doing v1->v6 "modifications", are they doing anything more than swapping the timestamp fields around? If so, they are at risk of generating non-compliant version 6 UUIDs.
Assigning a new |
@broofa, I think your last comment in this issue is now sufficiently covered in Draft 03 text. Either way, let me know if you think otherwise or if we can close this one out when we merge that PR. |
I need to review the latest edits, but I think we can close this out. I'll raise any new concerns in review comments or other existing issues. |
Playing Devil's Advocate: One of my first impressions of this proposal is that introducing three new versions seems "excessive".
Collectively, these three versions introduce a number of much-needed improvements. However I'm not entirely clear on what purpose the multiple versions serve. 'Seems like this is unnecessarily complicating the development of this spec.
For example, I would suggest the spec for version 7 provides the most value at present. It supports Unix timestamps, db-friendly byte-ordering, arbitrary sub-second resolution, and prohibits the use of MAC addresses, all of which are great. I.e. This is pretty obviously what most applications that need timestamp UUIDs should be using moving forward.
Meanwhile version 6 has nothing to recommend it over version 1 other than the reordering of
time_*
fields. I assume the nominal use case for this is to make it trivial to migrate version 1 uuids to a more db-friendly form? But I don't think that actually works because v6 currently prohibits the use of MAC addresses in thenode
field. Thus, converting from v1 -> v6 will be necessarily non-deterministic. (Thenode
field will have to be set randomly in order to remain in compliance with this spec, since there's no way of knowing for sure that the v1node
is not a MAC Address.)For anyone wanting to convert v1 uuids to v6 across a large, distributed system, that's going to be a huge issue.
As for version 8... well, I confess I don't really understand the use case for this yet. My first impression is that it's so abstract as to be almost meaningless. Technically, you could have a single timestamp bit ("The Boolean Epoch"?!?) with 121 bits of random data and still conform to the spec, no? I suppose (???) there's some value in allowing for arbitrary timestamp epoch/resolution/random bit construction of uuids but a spec that starts with, "The only explicitly defined bits are the Version and Variant leaving 122 bits for implementation specific time-based UUIDs" doesn't seem like much of a spec. It's more just a hand-wavy catchall that's going to invite people to create ad-hoc, proprietary sub-versions.
"It's a version 8 UUID, but we [Blargle Fargle Inc.] set bits 73-78 to
b110011
for our PulsyWulsy™ blood oximeter product."See also #29.
The text was updated successfully, but these errors were encountered: