On 5 September 2010 20:01, Laurence Rowe <l...@lrowe.co.uk> wrote: > On 5 September 2010 19:17, Martin Aspeli <optilude+li...@gmail.com> wrote: >> On 5 September 2010 15:29, Hanno Schlichting <ha...@hannosch.eu> wrote: >>> - Once we have intid's we can change the internal unique id of the >>> catalog from the physical path over to an intid. >> >> Perhaps we should consider using UUIDs instead of intids? > > We want to use intids because it is more efficient to intersect sets > of integers. They are only an implementation detail though, and it > should be possible to zap and rebuild your catalogue (assigning > different intids) without problems. > >>> >>> - Once we have parent pointers we can probably ditch storing metadata >>> in the catalog and load objects directly. >> >> Why do __parent__ pointers help here? > > With __parent__ pointers you can pull an object directly out of the > ZODB complete with it's location context. That means fetching the > title and description for an item is usually just an object load. > > What's not so clear about this is how we index an object's path and > it's allowed roles and users for the view permission. We should be > able to learn from Zope3 here though. > > Tthere are balances to be struck between read and write efficiency here.
It's worth noting here that the overhead of constructing the full location chain from a content item to the application root is much cheaper following __parent__ pointers up than traversing down the hierarchy. At each level of traversing you load the content object itself and search the BTree for the child (loading several BTree objects). With __parent__ pointers you can directly load each parent. I think this means that we probably won't have to worry about providing a cached absolute url metadata lookup or even cached roles and users as metadata - as these will only be calculated for a page's worth of content items. We will of course need an index on allowed roles and users and probably a descendants index (which zc.relation might provide), though only for those particular 'sections' to which searches are restricted. Laurence _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
