[Zope-CMF] Re: GenericSetup: How to use upgradeStep?

[Rob Miller]

Lennart Regebro wrote:
> On 9/25/07, Maurits van Rees <m.van.rees at zestsoftware.nl> wrote:
>> When you want to remove an index or column you can do that by editing
>> the profile and adding remove="True" to that index or column.  So this
>> upgrade can be represented as a profile edit.  But applying the
>> profile will empty the remaining indexes that are mentioned in that
>> profile.  So ideally I would want to apply the profile only once when
>> installing and rely on upgrade steps to handle any further changes
>> without applying that complete profile again.
>>
>> It seems the new upgrade steps do not really solve this particular use
>> case then.  (It can sure be handy for other things, no doubt about
>> that.)  But I had hopes to use them to work around this issue with
>> catalog.xml.  Apparently a workaround is no substitute for really
>> solving the problem. ;-)
>>
>> Is anyone going to the sprints after the Plone conference who wants to
>> take a shot at this with me?  Preferably someone with commit rights. :-)
> 
> Well, I made a monkey-patch that I haven't merged yet that only did
> that if the index definition had actually changed, and that was quite
> trivial. I would appreciate more people looking at this, since this
> was so easy I get suspiscious. :-) So at the Plone conf seems a good
> time.
> 
>>> performing a full upgrade, then, would require reapplying the profile
>>> configuration and running the upgrade steps.  reasonably the quickinstaller
>>> (or even the GS interface) could do this all as one step.
>> Right.  Or a warning could be displayed: "This profile has upgrade
>> steps available; do you want to run them?"
> 
> CPS listed all upgradeSteps whose version numbers where higher then
> the numbers of the last upgrades, and had a button to run them. You
> could also select which to run, and list old steps, and (re-)run them.
> 
> Since this is a merge of the CPS functionality (and thanks for that
> Rob, I never understood why Nuxeo branched GenericSetup instead of
> improving the original one, maybe there was a good reason)

sure.  i can only speculate as to why nuxeo made that choice, but i will note 
that it allowed them to simplify the idea of "version" to that of the entire 
CPS stack.  when i ported it back to GS, most of the work was adding support 
for per-profile versions, and per-profile upgrades.  seems reasonable for 
nuxeo to have punted on this extra work, since CPS didn't require it.

> I hope
> there may be something similar here?

yes, that interface was reproduced, with some changes to allow you to choose 
the profile for which you're running the upgrade steps.

-r