[Product-Developers] Re: Questions regarding GS upgradeStep
francois.barriere at atmel.com
Mon Sep 7 09:11:12 UTC 2009
On Sat, 5 Sep 2009 10:48:16 +0000 (UTC)
Maurits van Rees <m.van.rees at zestsoftware.nl> wrote:
> Francois Barriere, on 2009-09-04:
> > Hello,
> > [...]
> > When upgrading the Python code is executed by the regular import steps are
> > not (the changes in profles/default/diff_tool.xml) are not reflected.
> > I thought the upgrade would re-run the import steps of the profile...
> No. One of the goals up upgrade steps is to have a means to *avoid*
> having to apply the complete profile, as that can have unwanted side
> effects. Probably the best known example is the catalog.xml: if you
> specify an index there, then this index will be empty after applying
> the profile (or just this import step), even when it already existed.
OK, I understand.
> > Am I wrong? Should I force the import step from my Python code?
> > In this case, what is the use of the "profile" attibute of the
> > upgradeStep?
> The profile attribute marks this upgrade step as being an upgrade for
> the ATMEL.policy:default profile and not for say the Products.Poi
> If you want to reapply the complete profile in an upgrade step, you
> can do that like this:
> def applyProfile(context):
> # In an upgrade step context is portal_setup
This is what I have finally coded (almost, as I just need a single
step, in my case).
> BTW, this post of mine to the CMF mailing list with some notes about
> which source and destination numbers to use may be of interest:
Thanks. It contains usefull informations.
> Specifying source="*" like you do will always make this step available
> on the Upgrades tab of portal_setup, even right after you have run
> it. At least that is the case with Plone 3.0-3.3.
The old version was "unknown" so I used "*" to make sure it matches,
but after a test using "unknown" works too. I will test it against a
numbered version to make sure it is only triggered to migrate from
"unknown" to "0.3" (or make sure running twice the migration steps has
no side effect).
Francois BARRIERE ATMEL
Tel: (33) 0 442 53 61 98 13106 ROUSSET
E-Mail: francois.barriere at atmel.com FRANCE
Everyone knows that debugging is twice as hard as writing a program
in the first place. So if you're as clever as you can be when you write it,
how will you ever debug it? (Brian Kernighan)
More information about the Product-Developers