Uniqueness of v1 UUIDs if msecs is set. about uuid HOT 15 CLOSED

@ctavan - I believe when you and @pnegri suggested supporting an options argument, it was for the purpose of doing unit tests (in Cassondra, no less). I coded v1() this way because when doing unit tests, it's generally nice to have deterministic behavior so you can do things like assert.equal(uuid.v1({msecs: 123}), '139404b0-1dd2-11b2-9876-6339347e988e').

However if that's not the behavior we want it's certainly easy enough to change.

from uuid.

@ctavan - Is this more or less what you're asking for? b6dea0a

(Yeah, this feels better, imho. It does a better job of testing the code path used for default v1() behavior, which makes for higher quality test. And if a test needs a reproduceable uuid, it can just explicitely set nsecs)

from uuid.

@broofa I was fiddeling around with this today as well.

I think your commit is an improvement and it makes the test pass, that I've linked to, but I'm not entirely happy yet: My understanding of the RFC is, that for a given time (in 100ns) one single node can create exactly one UUID. If a regression in time is detected the clockseq has to be updated to avoid collisions. IMO this should also happen if there is only a regression of 100ns.

If we really need reproduceable UUIDs for unit-tests, we can specify everything including clockseq, if we don't specify the clockseq, we should expect unique ids. The msec/nsec thing is just a hack to work around javascript's poor clock-resolution so I think regressions in the nsec-scale should be honoured as well.

I've commited two more tests that I'd love to see pass: 0ac22a2

Do you agree on that? If you agree I'm also willing to patch node-uuid, just want to discuss it before...

from uuid.

Ah, and supporting unit-tests was not the only reason why we wanted the options. It was especially to enable us doing range-queries on v1-uuid-indexed columns in cassandra where you have to generate a uuid that represents the start of the range and one that represents the end of the range.

By the way only the time-part of the uuid matters in cassandra so clockseq and node can still be random. However for unit tests it's indeed convenient to be able to control everything.

from uuid.

I'm curious what you're thinking about my patch. It makes my two previously commited test cases work and leaves the rest unaffected.

from uuid.

@broofa Robert, can you already tell when you might find the time to look this through? I'd love to push development of node-cassandra-client a bit but we somehow rely on this issue being published to npm.

See http://code.google.com/a/apache-extras.org/p/cassandra-node/issues/detail?id=12

from uuid.

@broofa bump... Any news on this?

from uuid.

Hey Christoph, sorry for the delay on this. I'm just getting back to things after the holidays.

from uuid.

Looking at b8e34e7, adding msecs + nsecs just feels wrong to me - they're measured in two different units. And we keep them separate precisely because they can't be added with sufficient resolution when they're converted to the same unit system. I think there may be better way to represent time, using epoch and time options instead of the current msecs and nsecs options anyway, so let me post a diff (today, hopefully) and see what you think.

from uuid.

Oh sh*t, you're right of course. Adding msecs + nsecs makes no sense... I'll wait for you diff, thanks!

from uuid.

@ctavan, let me know what you think. I'll merge the RNG branch and rebase here in the meanwhile. :)

from uuid.

Hmm. git merge got away from me. Probably simplest to look at broofa/node-uuid@master...explicit_time and I'll figure out how to clean this up in the meantime.

from uuid.

@broofa Thanks for adding this, it's the clean solution of what I was trying to do. I have just one comment/improvement, see #28 .

from uuid.

merged to master, and npm published(!) Thanks again, @ctavan.

from uuid.

Thank you and a happy new year, @broofa :)

from uuid.