[Zope-dev] Re: [Zope3-dev] RFC: A proposal for ZODB schema migration in Zope 3

[Jim Fulton]

Chris McDonough wrote:
> I am keen on such functionality.  I will be working on something related
> to this in the near future to support a customer.  I would be interested
> in implementing something like this for Zope 2 as a result.  I had
> planned on implementing it as a completely external kind of thing, but
> maybe some support from Zope itself would be useful.

I think that the implemntation for Zope 3 will be pretty directly usable in
Zope 2.  I'm mainly limiting the scope to Zope 3 now, because the technique is
untried.

(One area that I've punted on is mutiple databases.  I think the mechanism
will need som expansion to handle multiple databases. In general, though
mounting is a god initial step, I think we need a better system for
dealing with multiple databases, but I just don't have the badwidth for
that now.)

> There is another practical problem that is logically related to this one
> which has the potential to be solved by the same machinery. I'm not sure
> we want to conflate the problems, but I mention it here just because
> it's possible that we do.
> 
> The "upgrade problem" isn't always limited to the updating the schema of
> database objects.  Sometimes an upgrade requires a mass update of
> "already-schema-current" objects.  For example, during an upgrade, you
> might want to reset local role values across a number of objects in Zope
> 2.  Or you might want to change a data value across a number of
> objects.  Or whatever.  This is a common problem in production, and
> usually it's solved by writing one-off scripts that connect to the
> database and do recursion and a commit.

To me, the term "schema" is (intentionally) vague enough to include
this sort of thing.

> There's nothing in your proposal that implies that the proposed
> machinery couldn't be used to perform these kinds of mass-update duties
> except the names "schema" (and maybe "generation").  So immediately the
> only thing I suggest (if we want to conflate the two problems) is to
> change the name "schema" to "state" and the name "generation" to
> "version".

I don't think this is necessary. I think that "schema" is general
anough and I like the term "generation" because it implies a step-by-step
evolution, which is key. Central to the proposal is that we can describe
the evolution of the data as a step=by-step progression and that we can
update a database through the orderly application of independent changes.

Feel free to ad a note to the proposal that the scope includes the sort of
scenario you described.

Jim
-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org