Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@danglingPointer Most commerce frameworks use sequence based, incremented numbers as order ids. They are human readable (even for normal users who would be confused by uuids) and if we have a single point of id assignment they also safe to use. The trick is to have a large enough sequence that cannot be rolled back.
-
@danglingPointer nah, sequences are fine as long as you never reuse them. Use a 64 bit or even better a 128 bit integer, and youre not going to ever use up the numbers in it.
So customers can place orders at our website, but some of the products are actually handled by a third party. We use a web service to communicate about these orders. Obviously, we need a way to uniquely identify each order, and decided with this other company that we would use a simple incrementing integer.
Last week, something strange happened: we could no longer cancel orders by their ID, because according to the web service, the orders were placed too long ago and were no longer eligible for cancellation. But I knew that could not be true: the orders were from last week. So I checked out database, turns out the ID's are not so unique: some refer to two or three orders. Somewhat worried, I contact the guy responsible at the other company and ask him how that could ever happen?
He: "Yeah, when we restart our server, the counter goes back to 1, you see. I didn't think that would be a problem...".
REALLY?! YOU DIDN'T THINK?
undefined
everyoneisunique fml