Chris Withers schrieb:
Jim Fulton wrote:

If someone can make something like this work without modifying ZODB, I won't object.

The only thing I'd like is to be able to:

- specify in policy that cross storage references should result in the target object being copied to the storage

I think the semantics to that aren't as obvious as they seem. This can go bad regarding consistency when multiple cross-database reference from various databases refer to the same object resulting in copies, then the copies can get out of sync.


- have an api to say "where this cross database reference exists, move the object to the referer's storage" (ie: only pasting an object or copying an object in the ZMI)

That and fixing the bugs in Undo and Pack, and that little niggle about accessing the referred object through the other-db referrer resulting in a KeyError if the referred-object's storage hasn't already been accessed.

A gut feeling I have about the situation is that we get bitten by the fact that features in the ZODB don't behave as orthogonal as we'd expect/like them to be.

The implementations of different features (like packing and undo) influence the outcome of other features that were not anticipated.

Does it have to be true that we have to worry about the full cartesian product of all possible states of all features? This seems like a risk for the long run and a chance for the long run to get this right.


gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to