On Sunday, June 8, 2014 10:09:12 PM UTC+3, Michael Bayer wrote: > > > On Jun 8, 2014, at 11:08 AM, Ofir Herzas <her...@gmail.com <javascript:>> > 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. > [Ofir] Seems like I missed that part. Thanks! > > > 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.
[Ofir] In that case, if an exception is raised in the migration process, > how can I fix it? (assuming that some migrations already passed, my schema > wouldn' t be in stable state) > > > > > > 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. [Ofir] I suppose it could be external to my migration script. Even so, is it possible to test it through sqlalchemy without using specific dialects? -- 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.
