[Nepomuk] [RFC] Nepomuk Resource naming convention

[Matthew Dawson]

On February 13, 2013 08:16:11 PM Vishesh Handa wrote:
> On Wed, Feb 13, 2013 at 8:08 PM, Matthew Dawson 
<matthew at mjdsystems.ca>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4061 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130213/fcab8075/attachment.p7s>