On February 13, 2013 06:04:12 PM Vishesh Handa wrote: > Hey everyone > > As you know nepomuk follows the following naming scheme - nepomuk:/TYPE/UUID > > - TYPE is either 'res' or 'ctx'. > - UUID is a 36 characters long generated via QUuid > > The UUID is supposed to be unique across one machine. It isn't meant to be > globally unique. However, we cannot be positively sure that the uuid > generated will be unique. So, we query nepomuk to make sure no other > resource with the same uuid exists. This query is expensive! > > It consumes about 10-13% of the execution time for certain tests > (DataManagementModelBenchmarks::storeResources_email). I would like to move > to a much simpler naming scheme - nepomuk:/TYPE/number. The number will be > an increasing integer which will start from 0. > > This way, we will not need to rely on uuid generation and won't have to > query the database during each creation. > > Comments?
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. 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. 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. 3) What happens when the number wraps around (if that is possible)? Matthew
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
