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.
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.
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.
If we don't want to conflate the two problems, do you have a suggestion
as to how to more uniformly deal with the data-value-update problem?
(BTW, it's very hard to follow threads following a message that is
cross-posted to a number of lists. I've made this mistake a number of
times in the past, and it's almost never worth doing as invariably I
miss something or need to reread every followup on every list).
On Sat, 2004-04-17 at 08:14, Jim Fulton wrote:
I've posted a proposal:
http://dev.zope.org/Zope3/DatabaseGenerations
for a framework for managing the migration of application/database schemas in ZODB
databases in an orderly manner. The proposal is to apply this new framework in Zope
3,
however, if it works well, it would be applicable to Zope 2 and other ZODB
applications.
Comments are welcome.
Jim
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
