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 - ZODB-Dev@zope.org