Lennart Regebro wrote:
On 9/25/07, Maurits van Rees <[EMAIL PROTECTED]> 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

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.


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to