ra at burningman
May 20, 2008, 11:23 AM
Post #3 of 4
(1123 views)
Permalink
|
|
Re: <genericsetup:upgradeRerunImportStep> (was Re: Multiple GS profiles per product)
[In reply to]
|
|
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 [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
|
