On Mon, 29 Jan 2024 at 19:32, Andrey M. Borodin <x4...@yandex-team.ru> wrote: > Even if the developer pass constant time to uuidv7(T) they will get what they > asked for - unique identifier. Moreover - it still will be keeping locality. > There will be no negative consequences at all.
It will be significantly "less unique" than if they wouldn't pass a constant time. Basically it would become a UUIDv4, but with 74 bits of random data instead of 122. That might not be enough anymore to "guarantee" uniqueness. I guess that's why it is required to use UUIDv8 in these cases, because correct usage is now a requirement for assuming uniqueness. And for UUIDv8 the spec says this: > UUIDv8's uniqueness will be implementation-specific and MUST NOT be assumed. > > On 29 Jan 2024, at 18:58, Junwang Zhao <zhjw...@gmail.com> wrote: > > > > If other timestamp sources or > > a custom timestamp epoch are required, UUIDv8 MUST be used. > > Well, yeah. RFC says this... in 4 capital letters :) As an FYI, there is an RFC that defines these keywords that's why they are capital letters: https://www.ietf.org/rfc/rfc2119.txt > I believe it's kind of a big deficiency that k-way sortable identifiers are > not implementable on top of UUIDv7. Well, let's go without this function. > UUIDv7 is still an improvement over previous versions. Yeah, I liked the feature to generate UUIDv7 based on timestamp too. But following the spec seems more important than a nice feature to me.
