Hacker News Reader

Comment by bullen | Hacker News Reader

Why UUIDs?

Proper, standardized, efficient support across the stack plus well known uniqueness guarantees about the the ids generated. Not that an ad-hoc solution can't be just as good, but why go through all the trouble of reinventing the wheel?

What benefits are you getting from the ad-hoc solution that you wouldn't with uuids? They were made for this.

> why go through all the trouble of reinventing the wheel?

Because now you depend on an UUID library and its attack surface.

In some environments it is crucial to reduce dependencies.

>Because now you depend on an UUID library and its attack surface.

I can appreciate reducing dependencies, but this is bordering on paranoia.

Whenever there's a "parse" method (as shown in this article), there's the possibility of poor implementation and exploitability.

Sorry, I do not get your point. If your inputs come from outside your system, you have to sanitize them, period. It would be the same thing for the original poster of this thread if the ids are being generated client-side. Besides, you're also running the risk of poor implementation for an ad-hoc system, which in my opinion is order of magnitudes larger than using a battle tested algorithm.

You can generate the UUID in the database. And UUID generation is something that you can also find in the standard library quite often, in both those cases you don't need to add an additional dependency.

Yeah, UUID generation should be from the DB. Have a stored procedure for putting creating the record and return the UUID from that, rather than it being provided from outside.

UUID is part of your language stdlib, or at least there will be widely tested dependencies for the formats. Are you that certain about the parser of your own custom format?...

I look up collisions every time I generate an ID and it's also sychronized when the node is broadcasted on the global cluster.

UUIDs use time and origin to make things unique something that is both an advantage and also a problem, say for example you want to hide origin and time?!

Also as danuker said, why add a dependency for no real benefit, Log4J should have proved to you that it's better to write minimalistic implementations yourself.

Finally there is a difference between reinventing the wheel and improving the wheel: http://move.rupy.se/file/wheel.jpg

I made a distributed database in 2000 lines of Java.

> UUIDs use time and origin to make things unique

Some UUID formats do. Format 4 has all bits (except the format bits) drawn from (P)RNG.

But then is uniqueness guaranteed?

From Wiki originally:

> the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion, which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%.

So in a theoretical sense, no, but in a practical sense, yes. The same is true for any custom ID format like yours as well. 128 bits is enough to never hit a dup though, so you don't need to go crazy.

Your database should be what authoritatively guarantees uniqueness at the end of the day — generate UUIDs assuming no collisions (which will ~always be true), but store in a UNIQUE index so things'll fail in case of a duplicate or a bug that results in trying to store the same ID twice.

No no.. why not uuids :D

Reply on news.ycombinator.com