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
_______________________________________________
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
