Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Also most well-designed systems only use the UUID as the representation format and use raw bits in performance-critical parts.


The raw bits are the UUID, the hex string is just a human-readable representation that also plays nicely with JSON.


Tell that to Django (well 5 years ago anyways iirc, don't know what it does now). Pretty sure it used to store uuids as strings columns in your sql.


I suppose Django wouldn't consider the speed gains of using raw integers in the database worth the hassle of dealing with binary data when you have to manually deal with the database somehow. I usually use string columns for UUIDs myself for the same reason.

It's also not given that it'll be a performance benefit, you probably receive UUIDs as strings from some client and probably want to return UUIDs as strings to the client, and that conversion isn't free.


Yep, looks like it does the right thing in PostgreSQL but not anywhere else [0].

https://docs.djangoproject.com/en/4.1/ref/models/fields/#uui...


I feel like it did strings in postgres too, not too long ago and I had a <brain explode> moment when I worked on a codebase and had to figure out why queries were terrible


Supposedly the behavior hasn't changed since at least version 1.8:

https://docs.djangoproject.com/en/1.8/ref/models/fields/#uui...

It may not have worked correctly on your project for some reason?


Actually now that I remember we were using MySQL and I was pushing for migrating to postgres partially for this reason, sorry it was a long time ago in startup time


Or to PowerBI, which will any UUID to a string even in joins. That cast + string comparisons + killing of indexes is not conducive to performant queries...


It’s a 128 bit integer - the serialization format does not change the fact.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: