1

on our system there's different routines from different languages (mainly C++ and python) interacting on same database tables.

In python, uuid1 implementation (MAC+time in ns) is my favorite since it reduce greatly the (low but still present) collision risk. MAC address disclosing is not a problem in our context.
But AFAIK, C++ implementation, with Boost lib for instance, is only uuid4 equivalent (pseudo-random).

Given that implementation between uuid4 in python and C++ (or Java if we also introduce it in the future) might be very different, I suspect that it could greatly increase collision risks.

Would you mix python's uuid1 and C++/Boost uuid4 ?
or go to uuid4 on both language ?
or go to uuid1 on both with another lib than Boost...

p.s.
a proposed "duplicate question" do not address my question since NEWID and Guid.Comb are not uuid1 nor uuid4 compliant (they mix time-based and pseudo-random bytes)

comte
  • 3,092
  • 5
  • 25
  • 41
  • http://softwareengineering.stackexchange.com/questions/130261/uuid-collisions – ivan_pozdeev Apr 07 '17 at 08:41
  • 1
    Possible duplicate of [UUID collision risk using different algorithms](http://stackoverflow.com/questions/3038023/uuid-collision-risk-using-different-algorithms) – ivan_pozdeev Apr 07 '17 at 08:42
  • The duplicate's for .NET but the underlying algorithms are the same. – ivan_pozdeev Apr 07 '17 at 08:42
  • on your second comment, it refers to algos mixing time and random, which is not the case for uuid1 (no random) or uuid4 (no time-based), so might be different case. – comte Apr 07 '17 at 08:46
  • at the end of day, I guess best, as suggested somewhere in your first link, is to test unicity before accepting uuid, no matter how they've been generated... but still curious about opinions, since in some context (not our), this test could be too overloading. – comte Apr 07 '17 at 08:49

0 Answers0