Thanks for the suggestion. I agree that it will be better to use an existing library instead of crafting our own solution so I've had a closer look at sqlalchemy-migrate.
I was previously in favour of using the application version number as the DB schema number but, now that I think about how sqlalchemy-migrate does it, I realise that having them separate allows upgrades to be automated even for development environments during a development cycle. This is a big plus, especially for a development team with casual contributors like this one. The sequential DB version number doesn't allow for branching but, as mentioned above, this will not be an issue for us. Sqlalchemy-migrate is intended to be used for database upgrades but because upgrade scripts can be written as either SQL or Python I think we can use it to do configuration upgrades. The one limitation I can think of is that it cannot migrate database connection configuration because the version number is stored in the DB. At this stage I will go ahead using sqlalchemy-migrate and see how I go. - Nathan ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Pytrainer-devel mailing list Pytrainer-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytrainer-devel
