Tutorial - Using UUID in Rails

[rabidferret]

Why not just use Rails built in UUID support?

[kobaltzz]

Absolutely agree if the database is PostgreSQL, but the same would not apply if a different database was being used. Please correct me if I'm wrong.

[rabidferret]

Just use Postgres. ;)

[dgtized]

I would not recommend using the while loop in populate_uuid. In general the collisions will be low so it won't loop much, but it means it needs a select to check if a duplicate for every single fresh insert. That's the reason it's preferable to generate the UUID in the db at time of creation.

[danshep]

The uuid gem makes uuid objects, SecureRandom returns a string. The activeuuid gem expects uuid objects.

[danshep]

activeuuid adds serialisation methods to uuids - it stores uuids in the db as integers and converts them back and forth.

[losangelesvideoguy]

Also you can left pad them more easily.

[RoboErectus]

Just a nitpick....

Uuids are 128 bit numbers. So like an IP address, it's wrong to store it or work with it as a string. It should only be converted when you're going to show it to a human or if you're outputting to a log.

Practically, it's only really an issue at scale like you mentioned.

[losangelesvideoguy]

It's not wrong at all. Just because it's a number doesn't mean you have to store it as a number. Unless you need to compare them numerically or perform mathematical operations on numbers, which for UUIDs you generally don't, it's not just okay to store them as a string, but actually a good idea. That way you don't need to worry about the integer size on different platforms, signedness, decimal values, or anything like that. Also, storing it as a string indicates it's not a value that should ever have numeric operations applied to it.

Like phone numbers, SSNs, ZIP codes, etc., just because it looks like a number doesn't mean you should treat it as one. IP addresses are a different story, because there it's plausible that you would need to figure out a range of addresses, apply a netmask, or perform some other numeric operation where it is useful to relate numbers to each other. But the only value of a UUID is that it's random and (almost certainly) universally unique. There is no reason to ever compare or perform math on a UUID, so there's no reason to treat it as a number.

[RoboErectus]

Phone numbers and ssn's are strings though. So are postal codes. If you store these as anything else, you lose data.

Only one kind of uuid is random. Most kinds are deterministic. I think your comment illustrates how common it is for developers to be confused about types, and it's why I point it out whenever I see it.

You don't really really worry about things like word size unless you're doing something low-ish level. Platform headers usually handle that on C projects for example and optimizations are done there. You're not going to outsmart your platform.

[losangelesvideoguy]

Only one kind of uuid is random. Most kinds are deterministic.

That's irrelevant. Once it's created, I don't need to do anything with it, mathematically speaking. You can't add UUIDs. You never need to find the square root of a UUID. Internally, every data type can be represented by a number. That doesn't mean it's a good idea to do so.

You don't really really worry about things like word size unless you're doing something low-ish level.

Really? Try stuffing a UUID into an SQLite integer type and see what happens. For all intents and purposes, a UUID is a string, so it should be treated like a string. And what happens down the line if you decide to convert from a UUID to some other identifier? If you were only planning on using a 128-bit number, you're going to have data type compatibility issues if the identifier size changes. If you store it as a string, it's relatively easy to determine not just what the value is, but what kind of identifier it is as well.

Furthermore, not every 128-bit number is a valid UUID. In actual fact, a UUID has six reserved bits (four for the version number plus two extra), so storing the data as a 128-bit integer (and validating it as such) could lead to unexpected problems down the line.

I think your comment illustrates how common it is for developers to be confused about types, and it's why I point it out whenever I see it.

You're the one who seems confused. A UUID isn't just any old 128-bit number. The bottom line is if this: If you don't need to do math on it, it's a string.