News for hackers. Stuff that matters.
Re:Problems with JPA/Hibernate by dale_glass on Sunday April 11, 2021 @06:18PM (#26773994)
Things like Twitter are special. I'm talking more about a generally sensible way of doing things, which one may need to deviate from in special circumstances.

Why would you want to sort by ID? Sort by something sensible, like the signup date instead. An autoincrement may stop corresponding to time if for instance at some point a database has an external dataset imported into it.

IMO, using an ID for anything other than an opaque identifier is asking for trouble.

Re:Problems with JPA/Hibernate by simonw on Sunday April 11, 2021 @06:52PM (#26774286)
I like IDs I can read out over a call, or recognize when I spot them in a log file. The few times I've used UUIDs for IDs I've later regretted it.
Re:Problems with JPA/Hibernate by mosdl on Sunday April 11, 2021 @07:29PM (#26774529)
Add a prefix to the if then.
Re:Problems with JPA/Hibernate by orf on Monday April 12, 2021 @04:17AM (#26777066)
> or recognize when I spot them in a log file

“14632” in a log file could be anything, whereas a UUID is way more explicit and searchable.

Re:Problems with JPA/Hibernate by simonw on Wednesday April 14, 2021 @03:57PM (#26812241)
I have frequently memorized IDs of things in systems I interact with often:

"Oh, it's user 14632 - yeah I've seen that ID crop up against this issue a bunch of times in the past"

I can't do that with UUIDs.

Re:Problems with JPA/Hibernate by orf on Wednesday April 14, 2021 @04:06PM (#26812340)
Sure, but I think you would usually optimize for the inverse - actively finding a needle in a haystack rather than passively hoping a needle falls in your lap. I get 1k hits for "14632" in our Splunk for the last 60 minutes, all of it rubbish. Durations, image sizes, worker IDs, primary keys, port numbers.

Search for a UUID and the results are guaranteed to always be relevant. Can't do that with integers.