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.
p.p.s.: until the rerunUpgradeStep tag is implemented, it's quite easy to
write a python function, callable by upgradeStep, that performs the same function.
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
