> On 25 Jan 2024, at 22:04, Sergey Prokhorenko <sergeyprokhore...@yahoo.com.au>
> wrote:
>
> Aleksander,
>
> In this case the documentation must state that the functions
> uuid_extract_time() and uuidv7(T) are against the RFC requirements, and that
> developers may use these functions with caution at their own risk, and these
> functions are not recommended for production environment.
Refining documentation is good. However, saying that these functions are not
recommended for production must be based on some real threats.
>
> The function uuidv7(T) is not better than uuid_extract_time(). Careless
> developers may well pass any business date into this function: document date,
> registration date, payment date, reporting date, start date of the current
> month, data download date, and even a constant. This would be a profanation
> of UUIDv7 with very negative consequences.
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.
On the contrary, experienced developer can leverage parameter when data
locality should be reduced. If you have serveral streams of data, you might
want to introduce some shift in reduce contention.
For example, you can generate uuidv7(now() + '1 day' * random(0,10)). This will
split 1 contention point to 10 and increase ingestion performance 10x-fold.
> 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 :) 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.
Jelte, your documentation corrections looks good to me, I'll include them in
next version.
Thanks!
Best regards, Andrey Borodin.
