My resources are limited so I can't test all possibilities (sqlalchemy version, alembic version, db type and version, etc.) before releasing my migrations so every once in a while I get to a customer and have to do some manual cleaning. Much to my dismay, I'm mostly using MySQL and Oracle so I guess I'll just have to live with it ...
Thanks again, Ofir On Tuesday, June 10, 2014 1:45:07 AM UTC+3, Michael Bayer wrote: > > > On Jun 9, 2014, at 3:10 AM, Ofir Herzas <her...@gmail.com <javascript:>> > wrote: > > > > On Sunday, June 8, 2014 10:09:12 PM UTC+3, Michael Bayer wrote: >> >> >> > 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) >> > > typically you test your migrations on a development database so that when > they run on a real DB they don’t fail. Then, if the backend supports > transactional DDL, a failed migration will roll back the whole operation. > So it’s only if you’re on a non-transactional DDL backend (Oracle, MySQL, > SQLite due to an issue in pysqlite) that you’d need to manually repair the > failed migration. But generally you want to be getting the scripts to be > perfect in a test environment first. > > >> >> > >> > 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? > > > im not familiar with such a method, sorry. > -- 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.
