News for hackers. Stuff that matters.
Re:Avoid UUIDv4 Primary Keys by vrighter on Monday December 15, 2025 @08:54AM (#46274563)
You can't take into account the fact that things change when you don't know what those changes might be. You might end up needing to either rebuild a new database, have some painful migration, or support two codepaths to work with both types of keys.
Re:Avoid UUIDv4 Primary Keys by mkleczek on Monday December 15, 2025 @11:57AM (#46277017)
Network protocol designers know better and by default embed protocol version number in message format spec.

I guess you can assign 3-4 bits for identifier version number as well.

And yes - for long living data dealing with compatibility issues is inevitable so you have to take that into account from the very beginning.

Re:Avoid UUIDv4 Primary Keys by vrighter on Tuesday December 16, 2025 @01:11AM (#46285335)
when I designed network protocols this is exactly what I did. I also did so in file formats had to create. But a database primary kea is not somewhere where that can be easily done.
Re:Avoid UUIDv4 Primary Keys by groundzeros2015 on Monday December 15, 2025 @10:59AM (#46276178)
You can’t design something by trying to anticipate all future changes. things will change and break.

In my personal design sense, I have found keeping away generality actually helps my code last longer (based on more concrete ideas) and easier to change when those days come.

Re:Avoid UUIDv4 Primary Keys by dpark on Monday December 15, 2025 @12:26PM (#46277469)
In my experience, virtually every time I bake concrete data into identifiers I end up regretting it. This isn’t a case of trying to predict all possible future changes. It’s a case of trying to not repeat the exact same mistake again.
Re:Avoid UUIDv4 Primary Keys by groundzeros2015 on Monday December 15, 2025 @03:33PM (#46280197)
I don’t disagree with that, I’m disagreeing with this comment that we can’t make protocol or data decisions that might change.
Re:Avoid UUIDv4 Primary Keys by dpark on Monday December 15, 2025 @03:56PM (#46280531)
I misunderstood then. I interpreted your comment to say that you eschew generalization (e.g. uuids) in favor of concrete data (e.g. names, email addresses) for ids in your designs.