3 ms·
I think the intriguing part was purposefully using the same sequence value for rows in multiple tables. I've worked with globally unique (to our application) i
by mnahkies 2y ago
I think the intriguing part was purposefully using the same sequence value for rows in multiple tables.
I've worked with globally unique (to our application) integer keys, and per table integer sequences (which obviously aren't globally unique), but I don't recall seeing anyone use a global sequence but purposefully reuse elements of the sequence before.
- collinvandyck76 2y agoI've seen this fairly recently and I was surprised to also see it in this article because I think that makes it twice that I've seen it in ~25 years.
- airstrike 2y agoThey may even be the same codebase!
- linux2647 2y agoIt’s kind of like an idempotency key assigned either by the request or generated at the beginning of processing that request
- mnahkies 2y agoIf the caller/consumer isn't choosing the idempotence key then I don't think it would act as a particularly good one. In this scenario the database is choosing the id during a transaction and so you'll only find out the value if the transaction successfully commits and the response makes it back to you. Generally you'd want the client to provide the idempotency key such that whatever failure occurs you know the value and can provide it on a retry such that the server can use it to prevent double entry / etc