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