Migration profiles for add-on products?
Martin Aspeli
optilude at gmx.net
Sat May 12 23:26:28 UTC 2007
Maurits van Rees wrote:
> The GS BBQ sprint branch looks promising. So we can probably drop
> this idea. But some (closing?) remarks are in order.
We seem to agree that this avenue is more interesting, so I'll only
argue for the sake of principle (and argument) now. Please indulge me
while I get a little argumentative, I do think this is an important
debate to be having. ;-)
Migrations are complex things. They can have unintended side effects.
They need to be easily testable. They need to be easy to debug.
All of those things tell me that it is an exceedingly (!) bad idea to
rely on implicit introspection of names of things that people register
(i.e. profiles) to determine what gets executed, when. It sound
incredibly (!) fragile to depend on introspection of version strings,
which can be based on nothing more than an assumption of conventions, to
calculate an upgrade path.
It also sounds likely that relying on version strings would limit the
vocabulary people can use to name their releases, in an arbitrary and
potentially frustrating way, lest it leads to subtle bugs. It's exactly
the kind of thing people end up "fighting the framework "for.
Conversely, it sounds error-prone to depend on abstract numbers that
have no explicit relation to the names that people associate with
versions. Migrations are about moving people between releases. Releases
have names that are used widely (in the package name, in tarballs, in
the cheese shop, on plone.org/products and so on). Having essentially
two parallel concepts of a version (a released (or even unreleased)
version string, and an abstract generation number) is surely unnecessary.
To control the order of execution of migration steps, I would much,
much, much rather add an extra line of code, from which I could set a
break point or add print statement or use some other debug technique. I
would also much, much, much rather that the path consisted of things
related to the releases that I make, so that I didn't need to remember
to increment some integer or keep a big list somewhere of which
generation integer related to each previous release, in case I had to go
back and debug some intra-version migration in the past.
In my experience, introspection and inference may sound neat, are fun to
code (but less fun to write tests for) for the framework writer, and
feel like they save everyone a bit of work, but they usually end up
costing a lot more grief in the long run. That's not to say we should
make everything long-winded and spelled out in excruciating detail. A
good balance in my mind, is to keep the locus of control in explicit,
easily debuggable, easily testable code, and let convenience be a matter
of defaults that can be explicitly overridden when necessary, rather
than the default position.
Martin
More information about the Product-Developers
mailing list