Re: Should intids be replaced with uuids for relations?
"Jens W. Klein" <jens-/[email protected]>
| Newsgroups | gmane.comp.web.zope.plone.devel |
|---|---|
| Organization | Klein & Partner KG |
| Message-ID | <[email protected]> |
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. regards Jens -- Klein & Partner KG, member of BlueDynamics Alliance ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/plone-developers