[Zope-dev] Refresh trashes acquisition

[Matthew T. Kromer]

Ross Boylan wrote:

>I find that when I refresh my product it destroys some of the
>containment relationships.  Things start failing, and as far as I can
>tell the only recovery is to completely rebuild the object.
>
>This is a big problem, and if anyone could explain what is going on
>and how to avoid it I would appreciate it.
>
>Here is the result of aq_chain before the refresh:
>[<RankQuestion instance at 8dd5620>,
><OriginalSuborder instance at 8c9f8d8>, <EMailBallot instance at
>8dfc870>, <__FactoryDispatcher__ instance at 8e73770>,
><ProductDispatcher instance at 83f0618>, <Folder instance at 8d5733
>
>and after
>[<RankQuestion instance at 8dee2d0>]
>  
>
[...]

>  
>

Hmm, while what you're referring to is "refresh" in the sense of a 
product reload, it's important to first state that *no* acquisition is 
expected to survive between transactions.

Each transaction must separately acquire its objects; if you try to pass 
wrapped objects between transactions or threads you're going to end up 
in trouble.

Secondly, when a product is refreshed, the extensionclass module will 
probably create new base classes for any ExtensionClass derived class 
file.  I dont *think* you can get much mileage out of knowing the id 
(address) of a class now, but be aware that a refresh will likely cause 
that address to change.  I have seen some bizarre errors where module 
"constants" changed because of a reload, and "is" tests broke because 
"is" tests the object address.

None of this is explicitly what you're asking about -- but I think what 
you're trying to do is in violation of the "no wrapped objects should be 
stored past a transaction boundary" rule.

However, I may be misreading your question too -- which is why I mention 
those two rules above so YOU can see if they make sense in your context.

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/