Dylan Reinhardt wrote at 2003-11-30 20:01 -0800:
...
You mean: when you do store *NON*-persistent objects within persistent objects, then ...
I meant what I said, but it's quite possible I was wrong. :-)
Otherwise, any change in your Zope hierarchy would write the complete hierarchy (which, of course, is not the case) as "ObjectManager" (a persistent object) does store its content items (again persistent objects) as attributes.
But isn't that *exactly* the problem you face if you do this in a non-ObjectManager object? Any change to any part of the object necessitates saving a copy of the *whole* object.
You do *NOT* face this problem when you use persistent subobjects whether they are in an ObjectManager or some other persistent object. You *DO* face this problem when the subobjects are not persistent.
I'm under the distinct impression that ObjectManager is special in this regard
This impression is not supported by the "ObjectManager" code ;-) "ObjectManager" is not special with respect to persistence...
and that's why it's the recommended solution for storing any non-trivial number of persistent objects. I'd greatly appreciate a correction if I've misunderstood something about that.
I think, I stated it already 3 times. Not sure, I can convince you. But, you may look at the "ObjectManager" code (--> "OFS/ObjectManager.py"). You will find no magic with respect to persistence. It is not even mentioned. What "ObjectManager" does: * provide creation/deletion/cloning hooks ("manage_afterAdd", "manage_beforeDelete", "manage_afterClone") * handle "ownership" and "Owner" role * "object*" methods to work with your content items You loose these services when you do not derive from "ObjectManager". But you do not loose elementary persistency behaviour. -- Dieter