[ZODB-Dev] What the ZODB really does

[Martijn Faassen]

Hi there,

The discussion on Gemstone isn't the first time that people seem to 
think the ZODB doesn't do what it actually does. If you have object A 
that points to B, and object C that also points to B, updating B will 
update B truly, and A and C will both aware of this change.

Quite a few smart people seem to be under the impression the ZODB 
doesn't actually take care of this. They believe that B will be 
persisted twice, once for A, once for C. This may be the case if B 
doesn't inherit from Persistent, but if it does, there really will only 
be that instance.

The ZODB is quite transparent that way. It's almost exactly like a pool 
(typically all stored in the same root dictionary) of Python objects. 
They can reference each other just fine. The only requirements I know of 
are:

* if you don't inherit your class from Persistent, or use a python 
builtin (which doesn't inherit from Persistent), things will be 
serialized multiple time, as far as I'm aware. (I may be wrong)

* if you have a non-Persistent subobject (like a list) and you change 
it, you need to manually flag the persistence machinery on the object 
that its subobject changed, with _p_changed. This is *only* necessary if 
some of the objects are not Persistent. For common built-in collections 
in Python such as list and dictionary there are replacements 
(PersistentList, PersistentMapping), and more advanced building blocks 
for indexes (BTrees), that don't have this issue.

Anyway, the misapprehension that the ZODB somehow does less than it does 
seems to be an easy one for people to develop. I think it would be 
important to show on the ZODB home page that this is truly not the case. 
This needs to be repeated early and often.

The *reason* people don't use hard references like this all the time in 
an application is that sometimes you want back references, and sometimes 
you want loose coupling. So that's when things are referenced by a 
string or a lookup or whatnot. Just like you sometimes put Python 
objects in a dictionary with keys. The wide application of such soft 
references seems to give people the impression you can't point the same 
object from tree X and Y at the same time.

Regards,

Martijn