I would like to know how an object/instance "knows" what class it is built from. This may be a silly question, but I just cant see how this works. The reason I ask, is that I am interested in building a system that may well involve moving objects from one machine to another and also upgrading objects from one version of a product to another. I want to understand more about the "glue" that ties an instance of a product to the product (ZClass or Python) and the classes it is derived from. How much of a python product can I change before the instances of that product no-longer know that they are instances of that product? Is is just the meta_type? What if I create two products with the same meta_type? Where can I read up on this? TIA Tom
From: "Tom Cameron" <tom@mooball.com>
I would like to know how an object/instance "knows" what class it is built from.
There is no general answer to that, it depends on what environment you are talking about. C++, Python, ZODB...
How much of a python product can I change before the instances of that product no-longer know that they are instances of that product? Is is just the meta_type? What if I create two products with the same meta_type?
Thats quite possible, but confusing. Youst copy a product directory to another product directory and restart the server to see what happens. Usually you get TWO listings of the product objects in the add box! So the class name is the fully qualified name of the class. I.e. OFS.Folder, or Product.ZCatalog.ZCatalog. Version handling of objects is not trivial, and I don't have much experience of it, but if you want it, I'd imagine this to be a useable way to go: In __init__ of a class, set self._version to the version of the class. Each time the internal structure changes, you need to upgrade the object, which can be done in __setstate__ I think. Check the version, to the upgrade and then again set _version to the new version number. I SHOULD start doing this on all my objects, but i'm too lazy. :-) If anybody have better ideas when it comes to object version management I'm all ears! :-)
I would like to know how an object/instance "knows" what class it is built from.
A persistent object in the ZODB knows what class its built from because it stores a fully-qualified name of the class, which includes the module name that the class lives in. So when a ZODB object is "woken up", the ZODB grabs the class definition by essentially doing an "import" of the class, e.g. import Products.Foo.Bar.Fudge If a class by this name can be found, it is used.
Where can I read up on this?
The developer's guide on Zope.org (persistence chapter) might have some data on this, but it's largely an implementation detail (albeit an important one ;-) -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"
=> Chris McDonough: => => A persistent object in the ZODB knows what class its built from because => it stores a fully-qualified name of the class, which includes the module => name that the class lives in. So when a ZODB object is "woken up", the => ZODB grabs the class definition by essentially doing an "import" of the => class, e.g. => => import Products.Foo.Bar.Fudge So I gather from this that it all comes down to the name - if I rename the product then I stuff things up. Is there anyway to query what class an object is instanced off? And also to edit this i.e. in the event that the class may have been renamed. Tom
From: "Tom Cameron" <tom@cameron.to>
Is there anyway to query what class an object is instanced off? And also to edit this i.e. in the event that the class may have been renamed.
No need to do that really. I moved a class from one file to another for clarity. The result was of course that all the instances broke... So I then created a dummy class in the old file: from Newfile import theClass class theClass(theClass): pass Now you have a class with the old name, that does exactly what the class with the new name does. If you want to get rid of the old objects, you could make a pythonscript that goes through the whole database and deletes the old objects and creates new ones with the same data.
On Sun, 9 Dec 2001 11:18:03 +1000 "Tom Cameron" <tom@cameron.to> wrote:
So I gather from this that it all comes down to the name - if I rename the product then I stuff things up.
Yes... although there is a facility for aliasing names when you move them named __module_aliases__. Here's an example I gave on the maillist a while ago for using __module_aliases__: 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. This is a hack.
Is there anyway to query what class an object is instanced off? And also to edit this i.e. in the event that the class may have been renamed.
All instances have an attribute __class__ that can be used to tell what class they are from. Cant edit an instance if it can't be loaded from the ZODB.
Is there anyway to query what class an object is instanced off? And also to edit this i.e. in the event that the class may have been renamed.
All instances have an attribute __class__ that can be used to tell what class they are from. Cant edit an instance if it can't be loaded from the ZODB.
You can also use the isinstance(class, klass) builtin, which plays nicely with inheritance. seb
participants (5)
-
Chris McDonough -
Lennart Regebro -
seb bacon -
Tom Cameron -
Tom Cameron