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