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