As always. Clear, detailed and to the point. Thanks Tim.
Actually, the z class isn't a subclass of persistent because it just holds data (has no methods) and never changes. Same goes to the lists of x and y, they tend to hold a few elements and also never change. The X and Y classes are more complex and are stored using BTrees. Reading this answer I understand that anything I store should be persistent, even if its a list I don't plan to edit. I was under the impression that a subclass of persistent will be larger in size for storage, so I avoided it in the cases mentioned. Is this true?

Thanks again for the help,

On Jun 20, 2005, at 4:00 , Tim Peters wrote:

[Yair Benita]

... suppose I have two different classes and both contain a list of a objects
from a third class:

class x has the attribute x.elements = [objects of class z]
class y has the attribute y.elements = [objects of class z]

As far as I understand python the lists x.elements and y.elements contain
pointers to the z objects previously defined.

Yes, Python lists always contain pointers -- even if it's a list of
integers, the list actually contains pointers to integer objects.  But
since that's always true, it's not much help in answering your real
question.  In general, pointers "make sense" only so long as an object
resides in memory.

What I wanted to know is how ZODB handles that (or maybe I should say: how pickle handles that) when saving to a file. Will the pointers be converted to a copy of the z class objects or will one copy of the z class objects be saved and than the x.elements and y.elements will still be a list of pointers?

Persistence has its own rules:  if an object is persistent (an
instance of a subclass of Persistent|), then its current state is
stored uniquely in the database, and all references to it just save
away (in effect) its persistent object id (oid, usually a 64-bit
identifier uniquely assigned to each persistent object, and which
retains its value for as long as the database exists).  There are no
exceptions to this for persistent objects.  Oids are effectively a
mechanism for building "persistent pointers", and apply only to
persistent objects.

If an object is not persistent (is not an instance of a subclass of
Persistent), it doesn't have an oid, and then there's very little
possibility to share references to it on disk.  Instead, on disk a
copy of its state will usually get made everywhere it's referenced.

So the answer to your specific question depends mostly on something
you didn't reveal:  does class z derive from Persistent?  If it does,
then _every_ reference on disk to an instance z1 is via z1's oid.  If
z doesn't derive from Perisistent, then almost all references on disk
to an instance z1 will be via a physically distinct copy of z1's full

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to