Re:Nanosecond timestamp collisions are common
by moffkalast on Friday July 21, 2023 @05:42AM
(#36811885)
You could also keep a global incremental index for that, assuming there's some authoritative server that has to be polled sequentially to get them.
Probably too much overhead when conflicting UUIDs are a few orders of magnitude less likely than the clients crashing from some random bug though.
So just prefix the node ID which is assigned when the node joins a swarm
Re:Nanosecond timestamp collisions are common
by Timon3 on Friday July 21, 2023 @09:12AM
(#36813350)
How is that easier or better? Now you're letting your infrastructure details bleed into your database.
They should bleed into your database. The database is part of your infrastructure and it contains details like where to find the replicas and so on
Re:Nanosecond timestamp collisions are common
by Timon3 on Friday July 21, 2023 @10:50AM
(#36814486)
Why? Tight coupling doesn't make things easier.
You’re complaining that the infrastructure details are bleeding into the intrastructure implementation?
Re:Nanosecond timestamp collisions are common
by Timon3 on Friday July 21, 2023 @12:02PM
(#36815448)
Infrastructure details are bleeding into non-infrastructure implementation. Your database content is not an infrastructure implementation.
the content is not, but it can use a database function, such as CURRENT_TIMESTAMP or RANDOM() can it not?
Although now I wonder if / how UUID v7 can do sequential keys on distributed systems. Mind you, on those systems "close enough" will probably be good enough, and sorting will be done by date instead of incremental ID.