Maurits van Rees-3 wrote:
>
> Martin Aspeli, on 2007-05-11:
>> I'm not sure it's desirable to hide things from portal_setup, since that
>> would probably have other side-effects. Maybe this is something we need
>> support for at the CMF level, though - different types of profiles being
>> listed differently in the UI.
>
> In zcml you can register your profile as providing either
> Products.GenericSetup.interfaces.BASE or
> Products.GenericSetup.interfaces.EXTENSION
>
> It could help to have this as an option:
> Products.GenericSetup.interfaces.MIGRATION
>
> Then portal_setup could list this differently.
>
Interesting. Are you up for exploring that option? The MIGRATION
constant/interface could be defined somewhere else than Products.GS of
course. :p
>> It may also be interesting to have a view (say, a control panel page?)
>> which
>> could list migration profiles (categorised by product?) and allow them to
>> be
>> invoked, therefore bypassing portal_setup for this purpose. With a big of
>> intelligence, we could also make sure that this executed sequences of
>> upgrade steps: alpha 1 -> alpha 2 -> beta 1 -> beta 2 -> beta 3 ... for a
>> particular product, from a particular start point.
>
> This sounds a lot like Zope 3 schema generations. See paragraph 19.4
> in Philipp's book. Or in code: zope.app.generations. A control panel
> page view is defined in the browser/ directory.
>
I know. The problem is that generations in Zope 3 aren't directly useful in
a CMF/Plone context, because the only context they get is the app root. You
don't know how many (if any) Plone sites are in the ZODB app root, nor which
one(s) (if any/all) should be migrated.
I experimented with a derivative that would let you link generations to CMF.
It may be useful. But since we have GS already, I'd rather use this.
Certainly, migratinos with GS are a lot easier than manua Python ones. It's
not always possible to do migrations in this way, but then we still have
custom import handlers (like importVarious) to fall back on.
> And that is actually what I have been experimenting with in this week
> on a branch of eXtremeManagement:
>
> https://svn.plone.org/svn/collective/eXtremeManagement/branches/mvr-annotations2/migrations
>
> The migration profiles part is not there yet. I started investigating
> that and got sidetracked into some Poi, Plone 3 and annotations
> issues.
>
>> Might be an interesting project. :) If it can be done in a light-weight
>> fashion, it'd be nice to have a single infrastructure for this that third
>> party products could depend on. importVarious-like steps could be used
>> where
>> GS profiles weren't sufficiently flexible. Any takers?
>
> The idea I am playing with on that eXtremeManagement branch mentioned
> above, is to add a property sheet 'generations' to portal_properties.
> I add an integer property called 'eXtremeManagement' and set that to
> zero. In evolve1.py I want to do some migration and then set the
> property to one.
>
For the record, I really don't like the way the default implementation of
generations uses file naming conventions like that. If we are going to have
naming conventions, why not have GS MIGRATION profile naming conventions?
We could still use utilities to register versions and the associated
migration step. In fact, forget the naming convention:
class IMigration(Interface):
id = schema.Int("The migration should be id 1, and then subsequent ones
should be id 2, 3 and so on")
to_version = schema.TextLine("Which version is this migration step
bringing you to?")
profile = schema.TextLine("The name of an extension profile to run as this
migration step")
class Migration(object):
implements(IMigration)
def __init__(self, id, to_version, profile):
self.id = self
self.to_version = version
self.profile = profile
then, you register a profile, like Products.Poi:migrate-1.0-2.0 and
Products.Poi:migration-2.0-2.1
and a few utilities:
v1_0_to_v_2_0 = Migration(1, "2.0", "Products.Poi:migration-1.0-2.0")
v2_0_to_v_2_1 = Migration(2, "2.1", "Products.Poi:migration-2.0-2.1")
<utility component=".migrations.v1_0_to_v_2_0"
name="Products.Poi.v1_0_to_v_2_0" />
<utility component=".migrations.v2_0_to_v_2_1"
name="Products.Poi.v2_0_to_v_2_1" />
(we need some thinking about how to separate different products here, maybe
a property in the utility? can't remember what zope.generation does).
Then, all you have to do is to work out the current version, find and order
the migration utilities for a given product, and execute those profiles
one-by-one.
Also, a propertysheet feels quite volatile. It may be nicer to have a local
utility which keeps track of the current installed version of each
migration-capable product.
> A first install of eXtremeManagement would probably just need to apply
> the main GS extension profile and set
> portal_properties.generations.eXtremeManagement to the latest
> generation number.
>
> I would actually want to shield the user from this migration by simply
> integrating this in the installer so that it automatically gets called
> on a reinstall of eXtremeManagement. I would say for add-on products
> this makes sense.
>
It ought to be an explicit action in Install.py when reinstall=True, but
that sounds sensible, yes.
Martin
--
View this message in context:
http://www.nabble.com/Migration-profiles-for-add-on-products--tf3727013s20094.html#a10432599
Sent from the Product Developers mailing list archive at Nabble.com.
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
