[ZODB-Dev] persisting "immutable" classes

[John Belmonte]

Dieter Maurer wrote:
> When you attach a non-persitent object to a persistent
> one, it will get part of this persistent object (as far
> as the persistency mechanism is concerned).
> Whether this is adequate is application dependent.

What do you mean by "it will get part of this persistent object"?

> Beware, however, that the containing persistent object does
> not recognized modifications of the non-persistent object.
> If you are not careful, modifications may be lost -- in an
> apparently non-deterministic fashion (it is in fact
> deterministic but asynchronous to "normal" operation).

My question was regarding immutable classes, where the "non-persistent" 
(in your words) object is never modified.  An example would be a class 
representing a time+ID tuple that has total ordering, for use as a key 
in a BTree job queue.   I'd like to know in this case if there are any 
other issues I should be aware of.  Also I'd like to know what kind of 
space overhead there is in deriving from Persistent, and whether doing 
so negates the savings I get by defining slots.

-John


-- 
http:// if  ile.org/