RE: [Zope] Python products - Versions in Zope
From: Andy [mailto:andy@agmweb.ca]
We separate dev staging and production totally by having totally different Zopes, only putting new versions live once tested (in theory :).
Well yes ... I do that too. But often I have a product up and running, and I have to make an updated product that is incompatible with the old one. What I wondered about is how to upgrade from version 1.0 to 1.1 of the same products as easy as possible. regards Max M
=?iso-8859-1?Q?Max=5FM=F8ller=5FRasmussen?= writes:
From: Andy [mailto:andy@agmweb.ca]
We separate dev staging and production totally by having totally different Zopes, only putting new versions live once tested (in theory :).
Well yes ... I do that too. But often I have a product up and running, and I have to make an updated product that is incompatible with the old one. What I wondered about is how to upgrade from version 1.0 to 1.1 of the same products as easy as possible. The main problem should be members the new objects have while the old do not.
There are two approaches, I know of: 1. define class variables as defaults for these new members class C: # new product new_member= None def method(self): if self.new_member is None: # may need to do something ... 2. instantiate the new instance variables in the "__getstate__" method. I expect a HowTo on zope.org for these questions. Dieter
On Tuesday 12 June 2001 03:08, Dieter Maurer wrote:
=?iso-8859-1?Q?Max=5FM=F8ller=5FRasmussen?= writes:
From: Andy [mailto:andy@agmweb.ca]
We separate dev staging and production totally by having totally different Zopes, only putting new versions live once tested (in theory :).
Well yes ... I do that too. But often I have a product up and running, and I have to make an updated product that is incompatible with the old one. What I wondered about is how to upgrade from version 1.0 to 1.1 of the same products as easy as possible.
The main problem should be members the new objects have while the old do not.
There are two approaches, I know of:
1. define class variables as defaults for these new members
class C: # new product new_member= None
def method(self): if self.new_member is None: # may need to do something ...
2. instantiate the new instance variables in the "__getstate__" method.
Can anyone tell me where __getstate__ is documented? -- Edward Muller - edwardam@home.com - edwardam@handhelds.org After 16 years, MTV has finally completed its deevolution into the shiny things network --The Onion
On Tue, 12 Jun 2001, Edward Muller wrote:
2. instantiate the new instance variables in the "__getstate__" method.
Can anyone tell me where __getstate__ is documented?
Python module pickle. Docs even have good example. Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Edward Muller writes:
Can anyone tell me where __getstate__ is documented? In the Python Library Reference (--> http://www.python.org), documentation of the module "pickle".
When I looked it up, I recognized that you would use "__setstate__" and not "__getstate__" to instantiate new members. Dieter
Max Møller Rasmussen wrote:
From: Andy [mailto:andy@agmweb.ca]
We separate dev staging and production totally by having totally different Zopes, only putting new versions live once tested (in theory :).
Well yes ... I do that too. But often I have a product up and running, and I have to make an updated product that is incompatible with the old one. What I wondered about is how to upgrade from version 1.0 to 1.1 of the same products as easy as possible.
Here's what I do: 1. Write a one-shot updater external method. I use my UpdateSupport product to help. If you have a look at http://www.zope.org/Members/chrisw/UpdateSupport/, and you'll see three example ones there. There's also loads of examples in Squishdot, I've been using this method for quite a while now :-) 2. Take down the Zope server and bring it up on another port, with the new version of the Product installed. 3. run the updater 4. take the server down and bring it back up on its usual port. The __setstate__ method Dieter suggested is very fragile and results in a __setstate__ method with lots of nasty old code hanging around in it that you can never get rid of in case someone decides to use your new code on a really old version. hope this helps, Chris
participants (5)
-
Chris Withers -
Dieter Maurer -
Edward Muller -
Max Møller Rasmussen -
Oleg Broytmann