On February 13, 2013 08:16:11 PM Vishesh Handa wrote: > On Wed, Feb 13, 2013 at 8:08 PM, Matthew Dawson <[email protected]>wrote: > > As it has been explained to me, the chances of generating duplicate UUIDs > > is > > so small as to not exist (even taking into account such things as the > > Birthday > > Paradox). I don't think worrying about it is worth it. > > Then maybe I should just remove the check? It'll be a lot simpler. Especially since you remarked a duplicate is not a big deal, yes you should be fine. For quick reference of the probabilities, Wikipedia offers: http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates
> > > That being said, the increasing number thing is useful too. Three issues > > I > > quickly forsee: > > 1) Is this a hot path? Since only one id can generated at a time, it > > needs > > proper locking. > > QAtomicInt True, but I meant you still have something that will be slower. Generating the random number requires no cooperation between pieces, but to increment the integer requires that nothing else does simultaneously. If it is not a hot path, it doesn't matter. > > > 2) It is critically important that you store the integer before the new > > resource, since otherwise you may end up with a duplicate in case of > > system > > failures. And checking for a duplicate's existance brings you back to > > square > > one. > > I'm not sure what you mean by store the integer. To presist the current maximum value, I assumed you store the integer somewhere on disk (in Virtuoso, in a KConfig file, etc). I was just pointing out the risk that if the storage of the value lags behind using the new value, you can end up duplicates again. > > > 3) What happens when the number wraps around (if that is possible)? > > That's not exactly possible. Ah, then never mind. -- Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
