whose alphanumeric order is the same as their
chronological order
Thanks, Tatu! I'm going ahead with it. Now if something goes wrong I'll
say: "But Tatu said..." (just kidding).
I've replaced Random in the code above with SecureR
I think you have to use time in milliseconds + network card number (mac
address) + a random number to genererate a uuid as microsoft .net framework. Iy
guarantees uniqueness in a cluster
Serdar
-
Thanks, Tatu! I'm going ahead with it.
Thanks, Tatu! I'm going ahead with it. Now if something goes wrong I'll say:
"But Tatu said..." (just kidding).
I've replaced Random in the code above with SecureRandom, for that extra
dose of randomness (my biggest worry was that Random self-seeds with
System.currentTimeMillis(), and there is som
On Wed, Jun 23, 2010 at 12:18 AM, David Boxenhorn wrote:
> Tatu, I did read your comments - and I appreciate them very much!
>
> I want someone to argue with me (using good arguments) since what I'm doing
> *does* seem weird to me - because no one else is doing it.
>
> What I mean by readable is t
Tatu, I did read your comments - and I appreciate them very much!
I want someone to argue with me (using good arguments) since what I'm doing
*does* seem weird to me - because no one else is doing it.
What I mean by readable is that the sort order of my UUIDs are obvious to
humans.
What I mean b
On Tue, Jun 22, 2010 at 11:54 PM, David Boxenhorn wrote:
> Having a physical location encoded in the UUID *increases* the chance of a
> collision, because it means fewer random bits. There definitely will be more
> than one UUID created in the same clock unit on the same machine! The same
> bits t
"Secondary reason is probably the ordering, and desire to stay
standards compliant."
My UUIDs are standards-compliant. They are of type 4. The type is encoded in
the format: --4xxx-8xxx-
.
On Wed, Jun 23, 2010 at 9:54 AM, David Boxenhorn wrote:
> Having a physical loca
Having a physical location encoded in the UUID *increases* the chance of a
collision, because it means fewer random bits. There definitely will be more
than one UUID created in the same clock unit on the same machine! The same
bits that you use to encode your few servers can be used for over 100
tr
On Tue, Jun 22, 2010 at 9:12 AM, David Boxenhorn wrote:
> A little bit of time fuzziness on the order of a few milliseconds is fine
> with me. This is user-generated data, so it only has to be time-ordered at
> the level that a user can perceive.
Ok, so mostly ordered. :-)
> I have no worries ab
A little bit of time fuzziness on the order of a few milliseconds is fine
with me. This is user-generated data, so it only has to be time-ordered at
the level that a user can perceive.
I have no worries about my solution working - I'm sure it will work. I just
wonder if TimeUUIDType isn't superior
On Tue, Jun 22, 2010 at 5:58 AM, David Boxenhorn wrote:
> I want to use UUIDs whose alphanumeric order is the same as their
> chronological order. So I'm generating Version 4 UUIDs (
...
> Is there anything wrong with this idea?
If you want to keep it completely ordered, it's probably not enough
As I understand it, the string value of TimeUUIDType does not sort
alphanumerically in chronological order. Isn't that right?
I want to use these ids in Oracle as well as Cassandra, and I want them to
sort in chronological order. In Oracle they will have to be varchars (I
think).
Even in Cassandr
Why not just use version 1 UUIDs and TimeUUIDType?
On Tue, Jun 22, 2010 at 8:58 AM, David Boxenhorn wrote:
> I want to use UUIDs whose alphanumeric order is the same as their
> chronological order. So I'm generating Version 4 UUIDs (
> http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Ve
13 matches
Mail list logo
