4 ms·

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

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.

danuker 5y ago
> 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.
- wizhi 5y ago
  >Because now you depend on an UUID library and its attack surface. I can appreciate reducing dependencies, but this is bordering on paranoia.
  - danuker 5y ago
    Whenever there's a "parse" method (as shown in this article), there's the possibility of poor implementation and exploitability.
    - toomanydoubts 5y ago
      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.
- fabian2k 5y ago
  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.
  - Akronymus 5y ago
    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.
- dtech 5y ago
  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?...
bullen 5y ago
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 http://move.rupy.se/file/wheel.jpg I made a distributed database in 2000 lines of Java.
- majewsky 5y ago
  > 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.
  - bullen 5y ago
    But then is uniqueness guaranteed?
    - mercantile 5y ago
      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.

danuker 5y ago

> 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.

wizhi 5y ago
>Because now you depend on an UUID library and its attack surface. I can appreciate reducing dependencies, but this is bordering on paranoia.
- danuker 5y ago
  Whenever there's a "parse" method (as shown in this article), there's the possibility of poor implementation and exploitability.
  - toomanydoubts 5y ago
    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.
fabian2k 5y ago
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.
- Akronymus 5y ago
  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.
dtech 5y ago
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?...

bullen 5y ago

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 http://move.rupy.se/file/wheel.jpg I made a distributed database in 2000 lines of Java.

majewsky 5y ago
> 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.
- bullen 5y ago
  But then is uniqueness guaranteed?
  - mercantile 5y ago
    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.