Martin Aspeli, on 2007-05-11:
> 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.
When you register a SchemaManager for your product in the zope 3 way
with some zcml, then on startup zope will evolve the Data.fs to the
minimum generation that you defined in that SchemaManager. That part
is indeed not useful for Plone add-ons.
But you do not have to register it. You can call your SchemaManager
with a different context. I can do this in a site with bin/zopectl
debug:
context = app['plonesite']
from Products.eXtremeManagement.migrations import UpgradeManager
um = UpgradeManager(context)
This calls the __init__ method of class UpgradeManager. There I can
call the SchemaManager ('sm') with the plone site as context. So then
I do the following to evolve the database to the minimum generation:
# evolve to the minumum generation
for gen in range(0, sm.minimum_generation):
# Go from gen to gen+1
sm.evolve(context, gen+1)
props['GENERATIONS_PROPERTY'] = gen+1
transaction.commit()
BTW, I see that UpgradeManager as the general part that can be
factored out into a separate product.
> 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.
generations and GS profiles are orthogonal. With GS migration
profiles you specify some upgrade steps. With generations you specify
which upgrade steps you want to perform.
In the example code in eXtremeManagement I have evolve0.py which
currently does the following (simplified for clarity):
def evolve(context):
"""Get the functionality in place for using generations.
"""
portal_props = getToolByName(context, 'portal_properties')
props = portal_props.get('generations')
props.manage_addProperty('eXtremeManagement', 0, 'int')
Instead of this I would want to apply a migration profile, much like
Plone 3 does it now. So something like:
loadMigrationProfile(context,
'profile-Products.eXtremeManagement.migrations:0')
But if that is the only thing that we really want to do in that
evolve() function, then it might be cleaner to overwrite the evolve
method of the base SchemaManager as defined in
zope/app/generations/generations.py
But that is for another email.
In other words:
- migration profiles are probably a workable idea, also for add-on
products
- generations could be an alternative to the current way of specifying
migration steps, possibly making it easier for add-on developers to
use.
I must say though that I have not really studied how Plone handles its
own migrations. Aside from migration profiles versus python code: are
core Plone developers generally happy with the way migrations of Plone
itself are done? Or would people be happy to try something new?
The other way around: is the current Plone migration code a good base
for add-on developers that they can easily use and hook into for their
own migrations? If so, is there an example product that shows how to
do this?
--
Maurits van Rees | http://maurits.vanrees.org/ [NL]
Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
I can assure you mine are still greater."
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
