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="";


        stepid="typeinfo" />

        purge="True" />

        title="Do something special"
        description="Does something special"



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:

       title="Workflow upgrade for my product"
       description="Same here"

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:

with a specific usage here:  (<-- ZCML)  (<-- 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.


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to