On Tue, Apr 24, 2012 at 05:52:24PM -0700, Rob Lanphier wrote: > As we do more frequent deploys, it's going to become critical that we > get database schema changes correct, and that we do so in a way that > gives us time to prepare for said changes and roll back to old > versions of the software should a deploy go poorly. This applies both > to MediaWiki core and to WMF-deployed extensions. > > I'd like to propose that we make the following standard practice:
I'm still new around here so pardon me if this sounds infeasible for us: In other systems I've worked before, such problems have been solved by each schema-breaking version providing schema *and data* migrations for both forward *and backward* steps. This means that the upgrade transition mechanism knew how to add or remove columns or tables *and* how to fill them with data (say by concatenating two columns of the old schema). The same program would also take care to do the exact opposite steps in a the migration's backward method, in case a rollback was needed. The migrations themselves can be kept in the source tree, perhaps even versioned and with the schema version kept in the database, so that both us and external users can at any time forward their database to any later version, automagically. I think that both Ruby on Rails and Python/Django (with South) employ such schemas and I've seen them work well in practice before. Regards, Faidon _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
