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/