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.
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?

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?

Thanks,
Ofir


On Sunday, June 8, 2014 5:22:46 PM UTC+3, Michael Bayer wrote:
>
>
> On Jun 8, 2014, at 9:12 AM, Ofir Herzas <her...@gmail.com <javascript:>> 
> wrote:
>
> I have an alembic migration script and I want to add some exception 
> handling but not sure what is the best practice.
>
> Basically, I have several issues to handle:
>
>    1. A change was already made and not needed (e.g. if I try to 
>    add_column, and this column already exists, I want it to continue)
>    2. A table is locked (if I try to perform some operation on a table 
>    and it is locked, I want to raise an exception)
>    3. 
>    
>    other exceptions?
>    
>    def upgrade():
>        engine = op.get_bind().engine
>        op.add_column('t_break_employee', sa.Column('auto', sa.Boolean()))
>        op.add_column('t_employee', sa.Column('settings', sa.Text()))
>    
>    
> I thought about adding a class to be used with the 'with' statement on 
> every change. Does it sound reasonable?
>
> for example:
>
>     def upgrade():
>         engine = op.get_bind().engine
>         with my_test():
>             op.add_column('t_break_employee', sa.Column('auto', sa.Boolean()))
>         with my_test():
>             op.add_column('t_employee', sa.Column('settings', sa.Text()))
>
> In that case, what are the exceptions I need to handle and how do I know 
> if a table is locked?
>
>
> seems a little risky, if your application wants to add a column, but 
> someone else added it in some other way, how can you be sure what else has 
> been done to that DB?    Skipping individual ops might address small issues 
> but not big ones.   If you really have a workflow where the target DB might 
> have manual changes applied, maybe instead you want to check for the 
> existence of the column?
>
> def upgrade():
>     inspector = inspect(engine)
>     cols = inspector.get_columns(“t_break_employee”)
>     if “auto” not in [c[‘name’] for c in cols]:
>         op.add_column(…)
>
> just a thought.
>
> as far as table is locked, if it’s persistently locked then your script 
> would just hang, just like every other application trying to get to that 
> table, until the deadlock elsewhere is resolved.
>
>
>

-- 
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