Changing class of objects in the ZODB
Hi, Does anyone have a good approach to changing the class of an object already stored in the ZODB? A site is using classes defined and customised in a product on the filesystem, and I want to split the product into two to separate the unmodified vanilla product, and customisations. I found a script from shane when I googled which purported to do this, but I did not understand exactly what it did and so am a bit nervous of using it. Also, it appeared to do it all in one transaction, which would not be practical for this site (too many objects). I had originally been envisaging doing something in __getstate__ for these objects, so when they were retrieved, they were updated and marked as having been changed so they would be committed at the end of the transaction. But I don't really know exactly what! I don't think it will work to use module_aliases because there will still be a class that can be imported from the original location. Any help much appreciated, Miles
Miles Waller wrote at 2006-6-12 16:58 +0100:
Does anyone have a good approach to changing the class of an object already stored in the ZODB?
This is *very* difficult. The main problem is that the class is usually coded (for efficiency reasons) in the persistent references to an object. As soon as the container is loaded from the ZODB, a ghost is created for its persistent reference using the class mentioned there. This means: it is not safe to change the class of a persistent object unless you although modify all its containers (otherwise, some persistent references remain with the old class. This potentially leads to non-deterministic behaviour). I usually solve you problem with proxy classes: When I want to refactor something, I do, but leave at the old place something like: from NewPlace import NewClass as OldClass -- Dieter
participants (2)
-
Dieter Maurer -
Miles Waller