On Jun 8, 2014, at 11:08 AM, Ofir Herzas <herz...@gmail.com> wrote: > Hi Michael, > Thanks for your prompt response and for the great tools you develop. > > I have 2 reasons for doing that: > 1. When I install my application on a new environment (blank db - no > alembic_version), Alembic tries to run all migrations but since I run > Base.metadata.create_all before Alembic upgrade, the schema is actually up to > date and an exception is raised.
when you run create_all(), you should also stamp the database with the latest migration. See the example at http://alembic.readthedocs.org/en/latest/tutorial.html#building-an-up-to-date-database-from-scratch for the way to do this. Otherwise you'd be running through a huge number of exceptions, but some of those statements might actually pass, e.g. if a migration adds a column that was later removed, it's a recipe for things to get out of whack. > 2. Sometimes in the development phase, I run the migration but then add some > other changes and wish to apply them also > > I agree that there might be better ways to accomplish what I want (insert the > proper alembic_version on bootstrap and use downgrade), but I do like the > notion of a migration that handles some known situations. > > Regarding your suggestion, I guess it'll work but what about begging for > forgiveness instead of asking for permission? Wouldn't it be better to catch > the exception raised and handle it? The issue is that the exceptions here aren't something that can be handled in an automated way, other than just skipping them all, but that really doesn't guarantee that the whole migration stream is going to run and leave the database in exactly the state that was started. > > Regarding the table lock, this is exactly what I'm trying to prevent (script > hang). Isn't there any test I could make before my script hangs? if tables in your DB is deadlocked, nothing is going to run against those tables. Wouldn't a test that is checking for an already locked database be something external to your migration scripts? To test for this typically means querying the database's system views for the presence of open locks. Depends on the platform. -- You received this message because you are subscribed to the Google Groups "sqlalchemy-alembic" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy-alembic+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
