[ZODB-Dev] question

[Shane Hathaway]

Christian Reis wrote:
> Well, that's half the equation. How do I update the "real" object with
> changes done to its clone, one I've decided to commit() the changes? The
> situation I have is that N different objects may refer to the cloned
> object, and I need to update the "real" one, not the clone.
> 
> Apart from updating __dict__ recursively down the subtree, is there a
> good way to do this?

No, there is not a good way, although updating the __dict__ of only the 
first object would be enough.  That is to say, the following would work 
in most cases:

def updateObj(old, new):
     old._p_changed = 1
     old.__dict__.clear()
     old.__dict__.update(new.__dict__)

>>Unfortunately, I'm pretty sure it's naive with ghosts (it may pickle 
>>ghosts as objects with no attributes) and it fails for ZClasses.  So a 
>>fully-elaborated version of the above is in the Ape product. 
>>Unfortunately, it's far more complex, but fortunately, it's known to work.
>>
>>http://cvs.zope.org/Products/Ape/lib/apelib/zodb3/utils.py?rev=1.1&content-type=text/vnd.viewcvs-markup
> 
> 
> I've got time reserved now to take a good look at Ape; let's use that
> time to learn something useful.

To be clear, the code mentioned has no dependencies on Ape.  It is a 
generally useful utility.

>>I'll let you in on a secret: previously, the transaction was directly 
>>notified of every object change, but today, the _p_jar gets the 
>>notification instead through its register() method.  The standard _p_jar 
> 
> 
> Hmm, did you mean s/gets/emits/ here? I thought the Connection notified
> the transaction, right?

Both gets and emits.  The Persistent base class notifies the Connection, 
then the standard Connection class notifies the transaction.  It used to 
be that the Persistent base class notified the transaction directly, 
which made it hard to try new ideas.

>>By subclassing Connection and overriding the register() method, you can 
>>try out your idea without changing ZODB.  You might get into crazy 
>>situations if some object gets modified by multiple groups, or by a 
>>group as well as the transaction, but you can structure your application 
>>in such a way to prevent that from happening.
> 
> 
> The way I see it (which is probably wrong X-) an object would *either*
> be in a group, or in the transaction's implicit "main group".
> 
> Or are you referring to problems with consistency that derive from
> multiple ZEO clients simultaneously performing "writes"?

No.  I'm thinking of side effects like indexing.  If you change an 
indexed object in a group, update indexes in that group, change another 
object in another group, and try to update indexes in the second group, 
it should probably fail.  However, there is no way to detect the 
conflict.  Perhaps that means changes in groups must not have side effects.

Shane