[Zope-dev] ZOBD and pointers

[Yair Benita]

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,
Yair


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
> state.
>