On Apr 26, 2:57 pm, Christian Boos <[email protected]> wrote: > With the upcoming 0.12b1 release, we will probably have a lot more > people upgrading their 0.11 database to 0.12, i.e. going from > database_version 21 to 26. This will likely trigger errors we're not yet > aware of. Actually I'm writing this as a follow-up > tohttp://trac.edgewall.org/ticket/9268, which reported such upgrade > problem. I'm wondering if we shouldn't make this upgrade a bit more > robust than it currently is, and more convenient to debug. In > particular, we could consider each upgrade step (i.e. each call to an > IEnvironmentSetupParticipant's upgrade_environment method) as being > self-contained. They already are in practice, as schema modifications > can't be rollbacked for the SQLite and MySQL database backends > > This reminded me of a discussion we had in Bitten > (http://bitten.edgewall.org/ticket/462) and indeed hodgestar later added > an explicit db.commit(), despite the Trac documentation advising to not > do it. > > Well, I think we should now simply invalidate this advice and say that > Trac not only takes care of doing a commit after each step, but that in > addition it should also be possible to perform finer grained commits > inside an upgrade_environment method if appropriate. It's certainly > appropriate for the trac.env.EnvironmentSetup.upgrade_environment method > (i.e. the place where we go through the trac/upgrades/db<version>.py steps). > > I tested the attached patch with sqlite, postgresql and mysql, for an > upgrade of a repository-less 0.11-stable environment upgraded to trunk. > Tell me what you think about it, but I think it's a worthy change to do > before the beta1. > > This was also the occasion to output something in the log about which > step is currently being executed. > > An interesting exercise for 0.13 would be to add an unit-test which > would create an environment with the database_version==1 schema, and > make it go through all the updates ;-)
Hear, hear. +1 on db commit after calling each participant, and letting the participants each commit as they please. Untested patch, but I really see no issues with this change - there may be some of course, but the advantages far outweigh any possible issues. Not least as a Trac upgrade is usually followed by a fresh new set of plugins that all may add to the upgrade currently being done in a single high-risk transaction. Hodgestar (Simon Cross) has done superb work for Bitten making unittests for the Bitten upgrades, and it certainly helped us work through various issues as we encountered bugs. :::simon https://www.coderesort.com http://www.ohloh.net/accounts/osimons -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
