Maurits van Rees wrote:
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.
Very true. However, I think using zope.generation directly isn't really
feasible. We can use its patterns, but when I tried to do this a while
ago, I found them to be more cumbersome than helpful for the use case of
migrating things in a Plone site. Your opinion may differ, of course!
I think basing the patterns on GS in the first instance makes sense,
though, since we're trying to advocate GS as "the" setup/configuration
mechanism.
- migration profiles are probably a workable idea, also for add-on
products
Agree. They're less painful than manually written migrations, by far.
They still require thought, though. For example, you can't really use a
rolemap.xml to add a role to the base settings for some permission,
because it stomps on existing settings. And some things just don't have
GS spellings. For the 80% case though, they are much easier and more
auditable, and portal_setup have tools to help you.
For the 20%, you can use an importVarious-type step and write Python
code as normal, but let the invocation of the GS profile be the thing
that controls triggering of the migration.
- generations could be an alternative to the current way of specifying
migration steps, possibly making it easier for add-on developers to
use.
Indeed. Like I said, I didn't like the default implementation in Zope
with evolveN.py, but that's possibly just personal preference. Using
utilities for the registry of versions makes sense to me.
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?
Migrations are always a pain. They require a lot of thought, since you
can't easily predict what people may have done with their sites. Using
something higher level, like GS, reduces the chance of error in some
cases, at the risk of being a bit more heavy handed.
portal_migration is very plone-core specific, and quite old. It works
okay, but it's not ideal. Registering a new migration step, when a new
version is released, is a bit cumbersome (but not too difficult). I
think a generation-utility pattern for specifying versions and steps is
better for third party products.
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?
No.
There are lots of useful patterns in the migrations themselves, such as
making sure things are separate functions which can be tested (and
testing is vital), and not ever making assumptions (like, don't die if
portal_types isn't in the portal, you never know what a user may do) and
make sure it's always safe to run migrations more than once (you may
need to "force upgrade" more than once to re-set something you messed
up, and it's really important for people using pre-release versions).
A secondary goal, I think, should be to have a migration *testing*
framework. Something as simple as a PloneTestCase sub-class which knows
how to run migration steps would be nice, for example.
And finally, we'll ultimately need "best practice" examples of how to do
migrations properly.
Martin
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
