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

[Rob Miller]

Maurits van Rees wrote:
> Rob Miller, on 2008-05-20:
>> it's maybe worth mentioning here that i _have_ recently started
>> using GS's upgrade machinery, and have been quite happy with it.
>> the one thing that i've missed, which i'd like to add to the GS core
>> if there's no strong objection, is the ability to easily register
>> re-running a particular import step as a part of an upgrade path.
>>
>> i propose introducing <genericsetup:upgradeRerunImportStep>, which
>> could be used as a standalone tag or nested within the grouping
>> defined by a <genericsetup:upgradeSteps> tag.  it would function
>> similarly to a regular upgrade step, except instead of running an
>> arbitrary callable handler, it would rerun a registered import step
>> within the context of the profile with which the step is registered.
>>
>> it would also support an optional boolean purge attribute, which would be 
>> passed in to the import step execution as the purge argument.
>>
>> a sample usage might look like this:
>>
>>
>> <configure xmlns="http://namespaces.zope.org/zope"
>>             xmlns:genericsetup="http://namespaces.zope.org/genericsetup">
>>
>>    <genericsetup:upgradeSteps
>>       profile="PACKAGE_NAME:default"
>>       source="1.0"
>>       destination="1.1"
>>       sortkey="10">
>>
>>      <genericsetup:upgradeRerunImportStep
>>         stepid="typeinfo" />
>>
>>      <genericsetup:upgradeRerunImportStep
>>         stepid="workflow"
>>         purge="True" />
>>
>>      <genericsetup:upgradeStep
>>         title="Do something special"
>>         description="Does something special"
>>         handler=".upgrades.do_something_special"
>>         />
>>
>>    </genericsetup:upgradeSteps>
>>
>> </configure>
> 
> 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.  they can be registered in all the usual manners, either 
via import_steps.xml or ZCML.  this is a reasonable requirement... you can 
only run upgrades against profiles that have already been loaded into 
portal_setup's step registry, and if your profile has been loaded, then any of 
the steps that it depends upon will be there.

> I *could* imagine for example a general workflow upgrade step that
> reapplies the security settings based on some new workflow settings
> that your product has just defined.  Although really that could be
> done like this, without needing to define a new zcml directive:
> 
>     <genericsetup:upgradeStep
>        title="Workflow upgrade for my product"
>        description="Same here"
>        handler="Products.GenericSetup.upgrades.apply_security_settings"
>        />
> 
> So GenericSetup would then define some default upgrade handlers, just
> like it defines some export/import handlers.
> 
> Would that suit your use case or are you thinking of something else?

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.

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.

-r