Actually, it is entirely possible to generate two and only two random xUID side by each and have them be duplicates. Such is the nature of randomness.
The only way to ensure that there is no collisions is to check whether the xUID is already in use/seen within the domain where it is used. A rowid generated by the ordinary method (if no records then 1 else max(rowid)+1) cannot have a key collision within its domain. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Richard Damon >Sent: Friday, 24 November, 2017 14:39 >To: sqlite-users@mailinglists.sqlite.org >Subject: Re: [sqlite] "BIGINT" doesn't act like INTEGER on table >creation [Bug] > >On 11/24/17 2:25 PM, Keith Medcalf wrote: >> Actually a UUID or a GUID has a 100% certainty of a collision, not >just a possibility of a collision. Just as all hash algorithms which >take something and generate a shorter "hash" or "checksum" will >always have collisions. Without exception and as an absolute 100% >certainty. There is no way to avoid this mathematical certainty. >> >> However, whether the absolute and unmitigatable certainty of a >collision is of any import or not is an entirely different matter. >> >Absolutely incorrect, for a UID. Perhaps if you are talking about >actual >hashes, you can say that there are always multiple (at least >potential) >messages that will generate the same hash value (but for a good hash, >the likelihood that one of them is sensible or even actually >generated >is minuscule). for a UID, while they are typically created by a hash >of >various information, including something that varies each time a >given >generator is used, what those inputs actually are is generally >unimportant, but are mostly provided to help make the 'randomness' of >the choice more 'random'. We are never really concerned with >'potential' >collisions, only actual collisions. > >One proof of the falsehood of your assertion is that we CAN fill a >database with some data using UIDs, and we will almost certainly not >get >a collision, while you assertion we will. > >Yes, there is a limit on how many entries we can generate before we >will >likely, or even certainly hit a collision, but if that number is >significantly higher than the number of records we will generate (or >even CAN generate), we can assume relative safety. With a 128 bit >UID, >the approximate point we need to worry about random collisions is the >order of 2^64, I suspect that creating an SQLite database with 2^64 >non-trivial records in a single table is likely going to have other >issues besides unique key collisions. > >-- >Richard Damon > >_______________________________________________ >sqlite-users mailing list >sqlite-users@mailinglists.sqlite.org >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
