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 

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

Reply via email to