On Jun 9, 2014, at 3:10 AM, Ofir Herzas <herz...@gmail.com> 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.

Reply via email to