On Saturday 9 November 2024 at 01:00:15 am GMT+3, Masahiko Sawada
wrote:
> the microsecond part is working also as a counter in a sense. IT seems fine
> to me but I'm slightly concerned that there is no guidance of such
> implementation in RFC 9562.
In fact, there is guidance of similar impleme
fields".
COMBINATION!!!
However, with the current performance of computers, method 3 is quite
sufficient without the addition of method 1.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
Dear Colleagues,
Althoughthe uuidv7(timestamp) function clearly contradicts RFC 9562, but
theuuidv7(timestamp_offset) function is fully compliant with RFC 9562 and
isabsolutely necessary.
Here is a quote from the RFC 9562to support thisstatement (RFC 9562:
Universally Unique IDentifiers (UUIDs
I think that for the sake of such an epoch-making thing as UUIDv7 it would be
worth slightly unfreezing this feature freeze.
Best regards,
Sergey prokhorenkosergeyprokhore...@yahoo.com.au
On Saturday, 13 April 2024 at 09:58:29 am GMT+3, Andrey M. Borodin
wrote:
> On 12 Mar 2024,
For every complex problem there is an answer that is clear, simple, and wrong.
Since the RFC allows microsecond timestamp granularity, the first thing that
comes to everyone's mind is to insert microsecond granularity into UUIDv7. And
if the RFC allowed nanosecond timestamp granularity, then the
Another source: Microservices Pattern: Database per service
|
|
|
| | |
|
|
|
| |
Microservices Pattern: Database per service
A service's database is private to that service
|
|
|
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 04:58:
BTW: Each microservice should have its own database to ensure data isolation
and independence, enabling better scalability and fault tolerance
Source: Microservices Pattern: Shared database
|
|
| |
Microservices Pattern: Shared database
|
|
|
Sergey Prokhorenko sergeyprokhore
Why not use a single UUID generator for the database table in this case,
similar to autoincrement?
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Friday, 22 March 2024 at 03:51:20 pm GMT+3, Peter Eisentraut
wrote:
On 21.03.24 16:21, Jelte Fennema-Nio wrote:
> On Wed, 20
I think it's better to leave Andrey's patch as is, and add another function in
the future with a customizable UUIDv7 structure for special use cases. The
structure description can be in JSON format. See this discussion.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On
Hi Jelte,
I am one of the contributors to this RFC.
Andrey's patch corresponds exactly to Fixed-Length Dedicated Counter Bits
(Method 1).
Andrey and you simply did not read the RFC a little further down in the text:
__
The followin
typo:
being carried to time step
should be:being carried to timestemp
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Tuesday, 30 January 2024 at 04:35:45 pm GMT+3, Andrey M. Borodin
wrote:
> On 30 Jan 2024, at 15:33, Junwang Zhao wrote:
>
> It's always
n is unclear and the phrase is most likely incorrect:
if large batches of UUIDs are generated at the+ same time it's possible that
some UUIDs will store a time that is slightly later+ than their actual
generation time
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Tuesday,
tween each other.
As for the documentation, it must be indicated that the UUIDv7 structure is not
timestamp + random, but timestamp + randomly seeded counter + random, like in
all advanced implementations.
Sergey Prokhorenko
sergeyprokhore...@ya
By the way, the Go language has also already implemented a function for UUIDv7:
https://pkg.go.dev/github.com/gofrs/uuid#NewV7
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Thursday, 25 January 2024 at 12:49:46 am GMT+3, Sergey Prokhorenko
wrote:
That's right! There
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.
The funct
cords with the old timestamp, etc. Horrible mistakes are
simply guaranteed.
Sergey Prokhorenko sergeyprokhore...@yahoo.com.au
On Thursday, 25 January 2024 at 09:51:58 am GMT+3, Andrey M. Borodin
wrote:
> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov wrote:
>
> From a prac
That's right! There is no point in waiting for the official approval of the new
RFC, which obviously will not change anything. I have been a contributor to
this RFC for several years, and I can testify that every aspect imaginable has
been thoroughly researched and agreed upon. Nothing new will
"Other people" think that extracting the timestamp from UUIDv7 in violation of
the new RFC, and generating UUIDv7 from the timestamp were both terrible and
poorly thought out ideas. The authors of the new RFC had very good reasons to
prohibit this. And the problems you face are the best confirma
ticle: https://habr.com/ru/articles/772954/
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Thursday, 18 January 2024 at 09:31:16 pm GMT+3, Andrey Borodin
wrote:
> On 18 Jan 2024, at 20:39, Andrey Borodin wrote:
>
> But 16455577420ns after 1582-10-15 00:00:00 UTC
1 Jan 1970 UTC, leap seconds excluded". The main
reason for using UTC is so that UUIDv7's, generated approximately
simultaneously in different time zones, are correctly ordered in time when they
get into one database.
Sergey Prokhorenko
sergeyprokhore...@yahoo.com.au
On Thursd
Andrey,
It is not clear how to interpret uuid_v7_time():
- uuid_v7 to time() (extracting the timestamp)
- time() to uuid_v7 (generation of the uuid_v7)
It is worth improving the naming, for example, adding prepositions.
Sergey prokhorenkosergeyprokhore...@yahoo.com.au
On Tuesday
21 matches
Mail list logo
