Christian Theune wrote:
- 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.

Sometimes having the transparency offered by ZODB is a bad thing. Would be nice if there was some way to say whether:

obj.a = a

...means "move obj to the same storage as a and replace reference in any databases with cross-storage references to obj's storage" or "create a cross-storage reference to a in obj's storage".

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.


I think we need to agree what features "zodb" offers and make sure they're tested for some "full set of supported operations"...



Simplistix - Content Management, Zope & Python Consulting
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to