Re: Should intids be replaced with uuids for relations?

On 6 March 2014 00:27, Wichert Akkerman <[email protected]> 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.
>

IOBTrees are 32bit and LOBTrees are 64 bit. Making a UOBTree to support
128bit would possible but probably not trivial in a cross platform manner.
But making all of the indexes twice as large is unlikely to be good for
performance.

>From my vague recollection looking at this stuff a few years ago,
zope.intid was really meant to replace catalogue rids (allowing you to
intersect across various catalogues.) The five.intid stuff always felt very
fragile to me so I tended to avoid it. Bad things happened when you lost
your intid catalogue! (In Zope3 you could store direct object references,
but that can't work in Zope2 where you need the acquisition context so the
five.intid implementation was necessarily far more complex.)

References should be stored canonically on content items as a uuid, that
allows you to rebuild your catalogue when necessary. For dexterity, I just
used the plone.formwidget.contenttree.source.ArchetypesContentSourceBinder
for my relatedItems fields, even in dexterity only sites. One field for
each relation type. It felt much more robust. You could then index the uuid
values in the catalog using a KeywordIndex to give you the ability to find
back references. Storing them as python integers would be more efficient,
though they'll still end up in OIBTrees as they're > 32 bits.

Laurence

------------------------------------------------------------------------------
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

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers