Tim McLaughlin wrote:
Thanks Chris, I'll hold on to that for a rainier day. I just worked this one out in a very roundabout way ;)
A product had gotten copied in that moved a Product class from one module to another even though everything else was the same. It seems that ZODB doesn't like that.
It sure doesn't. When it pickles an object, it says, here's a big binary blob that is the state of the object. The code for the object can be found in Products.MyProduct.MyModule.MyClass. When you move the code, ZODB understandably barfs.
If I remember correctly, there is a way to make an alias in an old location that points to a new location when you *must* move the code for whatever reason. I forget how it works though...
It works by putting a tuple of tuples in your Product's __init__.py module in a __module_aliases__ attribute at module scope. For example, PythonScripts have the following __module_aliases__ attribute. from Shared.DC import Scripts __module_aliases__ = ( ('Products.PythonScripts.Script', Scripts.Script), ('Products.PythonScripts.Bindings', Scripts.Bindings), ('Products.PythonScripts.BindingsUI', Scripts.BindingsUI),) .. this maps the module that *used* to be at Products.PythonScripts.Script to the module that is *now* at Scripts.Script, etc. This only works with modules and not with classes or other types.