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:
> 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]
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests