[Product-Developers] Re: GS upgrade step docs and tests
Gilles Lenfant
gilles.lenfant at ingeniweb.com
Tue Jul 1 09:37:03 UTC 2008
Le 30 juin 08 à 20:30, Rob Miller a écrit :
> Derek Richardson wrote:
>> Gilles Lenfant wrote:
>>> Le 26 juin 08 à 17:23, Derek Richardson a écrit :
>>>
>>>> My question. I have v1 of a product that contains GS for
>>>> utilities A and B. In v2, I am adding a utility C. If someone
>>>> upgrades, I want them to get C without re-installing A or B, to
>>>> prevent data loss. However, if someone installs v2 fresh, I want
>>>> them to get A, B, *and* C. Will registering an upgrade step for
>>>> v1 to v2 that installs C accomplish this? I imagine it does, as
>>>> the upgrade step would be of limited utility without this
>>>> functionality, but haven't seen this explicitly stated anywhere.
>>>
>>> Yes it does. The handler of an upgrade step is just a function
>>> that has the portal_setup object(*) as argument. This function
>>> only needs to add C, either programmatically or by running a GS
>>> import step like this :
>>>
>>> def myUpgradeHandler(setuptool):
>>> """Add only C to existing config"""
>>> setuptool.runAllImportStepsFromProfile('profile-
>>> my.component:upgrade_v1_v2', ...)
>>>
>>> Of course you need to register with some ZCML that extension
>>> profile (upgrade_v1_v2 for my.component) that only contains
>>> features of C. when the defaut profile contains A, B and C.
>>>
>>> (*) I would have preferred a "context" as in usual setup handlers,
>>> such functions from setup handlers could be used easily from
>>> upgrade steps.
>>>
>> Aha! So, I need to add the registration of C to the default profile
>> to get it installed when someone does a fresh install *and* add an
>> upgrade step that installs it when someone does an upgrade? I was
>> hoping that the upgrade step would be automatically run after the
>> default profile import, so that I would only have to do it in one
>> place. Oh well...
>
> for now, yes, unfortunately. this should improve soon, though.
> sometime in the coming weeks i plan on implementing a
> <genericsetup:rerunImportStep> tag, which would be able to be used
> in all the places that a <genericsetup:upgradeStep> tag is currently
> supported. the rerunImportStep tag will be short-hand for saying
> "upgrading from version X to version Y requires import step Z to be
> re-applied to the site".
>
> when this is working, the process will be to a) modify the profile
> definition and b) add the <genericsetup:rerunUpgradeStep> tag to
> specify that the right import step be applied during the upgrade
> process.
>
> i think this is acceptable, and (more importantly, perhaps) i
> _don't_ think we should try to reduce it any further than this.
> this feels to me like the right balance btn minimizing developer
> effort and maintaining explicitness w/ what happens for each upgrade.
>
> -r
>
> p.s.: while the example given above will work, and while Plone
> itself uses them, i'm generally not in favor of defining specific
> "upgrade" profiles as full-fledged extension profiles. now that you
> can use upgradeSteps, there's not really a need for separate upgrade
> profiles. if everyone started registering upgrade profiles for
> every version bump for every product, the profile registry would
> quickly become a major PITA to use.
Hi,
This is just an example. Of course a full upgrade profile would be
overkill to add only a couple of properties. The developer has just to
use well balanced and suited resources to the stuffs added at upgrade.
Cheers
--
Gilles Lenfant
INGENIWEB (TM) - SAS 50000 Euros - RC B 438 725 632
Bureaux de la Colline
1 rue Royal
92210 Saint Cloud
web : www.ingeniweb.com - « les Services Web Ingénieux »
More information about the Product-Developers
mailing list