I have multiple installations of a TTW product that stores it data in the ZODB. I do not have direct access to all the installations and need to send clients an update script to update some of the methods accross all installations. I thought one way of doing it is to write a python script that imports the ZODB and upload method contents from files distributed with the script. Any other ideas? Roché
Roché Compaan wrote:
I thought one way of doing it is to write a python script that imports the ZODB and upload method contents from files distributed with the script.
Any other ideas?
Have a look at the UpdateSupport Product. I use it to exactly these kind of updates. cheers, Crhis
I can't see how UpdateSupport will really help me in my case. This is a ZPatterns application and all product classes are ZClasses. I want to update some of the methods inside specialists without messing up persistent data in racks. If you use the ZODB as storage with a ZPatterns app the location of racks becomes problematic quickly. I also want to make the updating as simple as possible without somebody having to install other products to make updating possible. Roché
Have a look at the UpdateSupport Product. I use it to exactly these kind of updates.
cheers,
Crhis
Roché Compaan wrote:
I can't see how UpdateSupport will really help me in my case. This is a ZPatterns application and all product classes are ZClasses. I want to update some of the methods inside specialists without messing up persistent data in racks. If you use the ZODB as storage with a ZPatterns app the location of racks becomes problematic quickly.
..well doing this kindof thing is exactly what I use it for: you write a new version of a product which has attributes in different places in classes, etc, and you need to update old instances.
I also want to make the updating as simple as possible without somebody having to install other products to make updating possible.
Well, if you don't want them installing one more product and an external method, then you're left with __setstate__ hackery which is notoriously unreliable :-S cheers, Chris
..well doing this kindof thing is exactly what I use it for: you write a new version of a product which has attributes in different places in classes, etc, and you need to update old instances.
What do you do with entirely new methods?
Well, if you don't want them installing one more product and an external method, then you're left with __setstate__ hackery which is notoriously unreliable :-S
Installing a python product should be ok, but I'd like to automate the installation of the external method because none of the users currently have management rights. Thanks so far Roché
..well doing this kindof thing is exactly what I use it for: you write a new version of a product which has attributes in different places in classes, etc, and you need to update old instances.
What do you do with entirely new methods? <cw> As in ZClass method? Add them using the normal manage_add* stuff. Utility.py in Squishdot has methods to do this. </cw> Installing a python product should be ok, but I'd like to automate the installation of the external method because none of the users currently have management rights. <cw> Well, you could write a product that does monkey patching and updating on initialisation and the delete itself off the filesystem ;-) </cw> cheers, Chris
Well, you could write a product that does monkey patching and updating on initialisation and the delete itself off the filesystem ;-)
That's what I did in the end. But it turned out to be quite a exercise (it deletes, updates, creates objects, adds properties and changes proxy roles) giving me losts of insight into Zope itself. Thanks for your help Roché
participants (3)
-
Chris Withers -
Roch'e Compaan -
Roché Compaan