On Oct 24, 2008, at 7:51 AM, Jim Fulton wrote: > A few high-level observations. (I don't have time to get into the > weeds.) > > 1. The parent pointers used in Zope 3 are, obviously, a problem for > ZODB exports. You've already noticed this. > A possible way to mitigate this would be to extend the export > API to be able to omit objects from the export. > Then, when copying a tree, you could tell it to omit the parent > of the root. There would have to be some way > to tell it what to use instead.
Since Export appears to work by following OID references, I guess a stupid simple way of providing alternate values/lookups for certain OIDs might work. I'm not sure how zc.copy / zope.location.pickling.locationCopy actually do their work (the guts of pickling are a mystery to me), but I imagine that there could be a way of providing something similar for exporting - basically some way of finding out if a referenced object is outside the containment zone and providing an alternative value/ reference. > 2. I doubt that blobs have been factored into ZODB exports. This is, > obviously, an oversight. They're actually factored in quite well. The copy stunt which I use to kill the __parent__ link of the root exported object is the problem. This is the scenario I now worry about - how Blobs will work in applications like Zope which provide 'copy/paste' functionality. > 3. I think that zope.fssync/zope.app.fssync might provide a better > export/import technology, although they *may* require more work. On > the up site, they are more pluggable. We are, *finally*, about to > start using zope.fssync in a production application. I'll take a look at those. I think they're what we (Bottlerocket) need (at least at a conceptual level). Thanks, Jeff Shell [EMAIL PROTECTED] _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev