[ZODB-Dev] Blobs, Copies, and Exports (Zope 3)

[Jeff Shell]

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
jeff at bottlerocket.net