On Wednesday, June 1, 2011 at 10:41:29 PM, "Nathan Jones" <nat...@ncjones.com> wrote: > 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. Excellent, glad that this looks usable here
> 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. Right - you don't want to have to install a meta-db to track the version number of the configuration that contains the actual database connection that ... > At this stage I will go ahead using sqlalchemy-migrate and see how I > go. Great, hope it is helpful Cheers David ------------------------------------------------------------------------------ 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
