Re: Should intids be replaced with uuids for relations?

On Thu, Mar 6, 2014 at 3:23 AM, Jens W. Klein <jens-/[email protected]> wrote:
> On 2014-03-06 09:27, Wichert Akkerman wrote:
>> On 06 Mar 2014, at 09:26, Asko Soukka <[email protected]> wrote:
>>
>>>> Wichert Akkerman <[email protected]> kirjoitti 6.3.2014 kello 10.07:
>>>>> Using intids as the keys for catalog indexes is ideal and was done intentionally, because integers can be compared more quickly than strings, so IOBTrees are faster (at least, that's my understanding of why intids were used). This is also one reason the ZCatalog uses an integer rid (record id) internally instead of some other identifier.
>>>>
>>>> That argument does not quite make sense to me: a UUID is just a 128-bit digit number, so if you store that as an integer instead of a formatted string you should have exactly the same advantages.
>>>
>>> Can IOBtrees handle 128bit int keys? (I remember having success with only 32bit doc ids with zope.index.)
>>
>> I don't know, but if not I'm guessing that could be added reasonably easy.
>>
>> W.
>
> There are at least 64bit integer supporting LOBTrees.
>
> So - without knowing the underlying implemenation - 128bit should be
> possible too.

Not sure what the performance implications of this are, but unlike a C
long long (64 bit), you would have to implement the key in C as a
struct of two C long long values.  It might also be possible to
partition indexes of a UUID arbitrary-precision integer value in pure
python into multiple LOBTrees by segmenting the high and low bit
values into two distinct indexes and join results, and the expense of
extra operation on indexing and query.

Still, I don't think 64-bit long integers leave us wanting for space
WRT _internal_ document IDs, I just prefer the idea of having it be
RIDs in the catalog to any kind of special intid utility.

Sean

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk