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

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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to