[Zope-CMF] Re: <genericsetup:upgradeRerunImportStep> (was Re: Multiple GS profiles per product)

[Maurits van Rees]

Rob Miller, on 2008-05-20:
> Maurits van Rees wrote:
>> And where are the original typeinfo and workflow upgrade steps
>> defined?  Are they in some other zcml file of your product?  Or would
>> they be general upgradesteps defined by GenericSetup, available for
>> any products?
>
> they're expected to be import steps that are already registered with the 
> portal_setup tool.

Ah, I was confusing upgrade steps and import steps.  Makes more sense now.

> that's not quite the case i'm talking about.  i'm talking about a situation 
> where you've edited the my_workflow.xml file in your GS profile, and you want 
> to express (using GenericSetup's upgrade step registry) that the 'workflow' 
> import step needs to be re-applied to the site.  this is extremely common... 
> i'm always having to keep track of which import steps i need to re-run for a 
> particular upgrade.
>
> in theory, all upgrade code should always be idempotent, so you _could_ argue 
> that you should always just re-import the entire profile.  but sometimes 
> people make mistakes and a particular step is not idempotent.  and 
> re-importing the entire profile might be a much heavier operation than simply 
> re-applying a fairly trivial config change.  i much prefer to mark specific 
> steps as needing to be re-run.

In Plone land I am used to just reapplying the entire profile.  You do
not want that for e.g. catalog.xml when that defines an index, which
is why I have switched to defining indexes in python code again.  That
could be a reason for having better upgrade support like you propose.

> it CAN be done w/o a custom tag... i'm currently using a 'rerun_import_steps' 
> handler, you can see the implementation here:
>
> http://tinyurl.com/5d69my
>
> with a specific usage here:
>
> http://tinyurl.com/6m7sjm  (<-- ZCML)
> http://tinyurl.com/6zhtzw  (<-- handler)
>
> but this is still too much boiler-plate for me.  i have to stub out
> my own data structure to store the steps that need to be run for a
> given upgrade path, including whether or not the step should be run
> in purge mode.  all of this can be expressed in a new ZCML tag very
> easily, eliminating the need for boiler-plate code.  as an added
> bonus, it makes your upgrade registration ZCML more informative, you
> can see at a glance everything that needs to happen for a given
> upgrade path.

Okay, makes sense.

-- 
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]