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
> 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/
> 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).
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org