On May 17, 2010, at 1:13 PM, Chris Withers wrote: > Hi All, > > I want our production systems to start caring about the versions of their > schemas. sqlalchemy-migrate was the first project I came across which > addresses this. What other projects should I look at in this area, or is > sqlalchemy-migrate the obvious choice? > > If it is, how can I, in my application, check what version of the schema the > current database is? (the idea being that the app will refuse to start unless > the schema version is that expected by the app) > > Related: how can I short circuit this when the database is empty and bump the > schema version up to the latest for the app? (ie: dev instances, where the > process is to blow the db away often so no need for migration)
sqlalchemy-migrate is the obvious choice. I am also developing a micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) in conjunction with my current work project but not all features have been implemented yet - its expected that I'll be getting them in a more polished state in the coming months. The Migrate project can of course steal any and all desireable features and code from Alembic freely as I would like sqlalchemy-migrate to remain the default choice. as for the related issue, I think its best that your setup provide a "setup-app" type of command which generates an initial schema, and embeds the current migrate version number. Here's a snip of a related Pylons websetup.py: from migrate.versioning.api import version_control, version, upgrade from migrate.versioning.exceptions import DatabaseAlreadyControlledError # Create the tables if they aren't there already meta.Base.metadata.create_all(bind=meta.engine, checkfirst=True) # setup migrate versioning table if not present try: latest_version = version("migrate") version_control(pylons.config['sqlalchemy.url'], "migrate", version=latest_version, echo=True) except DatabaseAlreadyControlledError: log.info("migrate table already present") # do any migrate upgrades pending... upgrade(pylons.config['sqlalchemy.url'], "migrate", version=latest_version, echo=True) The migrations system should only be used for changes to an existing schema. Other "check this before running" types of functionality can be accomplished similarly. As a side note, I also have an elaborate monkeypatch to migrate to get it to work with transactional DDL. Simple support for transactional DDL is one of the goals of the new tool I am writing. If you're not on Postgresql or MS-SQL, then you can't use transactional DDL anyway. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
