New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration tries to delete already-deleted key from deleted column. #247

Closed
sqlalchemy-bot opened this Issue Nov 21, 2014 · 7 comments

Comments

Projects
None yet
1 participant
@sqlalchemy-bot

sqlalchemy-bot commented Nov 21, 2014

Migrated issue, originally created by Andrew Magee (@amagee)

I'm using PostgreSQL. I deleted a non-nullable column from a table, which generated a migration like this:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.drop_column('cuser', 'username')
    op.drop_constraint('cuser_username_key', 'cuser')
    op.drop_index('cuser_username_key', table_name='cuser')
    ### end Alembic commands ###

But the second line, the drop_constraint, throws an exception because the "cuser_username_key" constraint no longer exists at that point. It seems that the drop_column call deletes it, because the constraint does actually exist if I inspect the table.

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Changes by Andrew Magee (@amagee):

  • edited description
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Michael Bayer (@zzzeek) wrote:

OK so two approaches, one is we get constraints to be ignored if an owning column is to be dropped, however, it might be better if we just put the constraint drops above the column and still include them; #232 seems to indicate that MySQL's drop column needs the constraints to be dropped explicitly in any case.

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Michael Bayer (@zzzeek) wrote:

also, there is drop_constraint() and drop_index() here for the same name. the PG dialect is supposed to detect that kind of condition so it's....unexpected that it is generating both. but im going to ignore that here.

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Michael Bayer (@zzzeek) wrote:

  • A change in the ordering when columns and constraints are dropped;
    autogenerate will now place the "drop constraint" calls before
    the "drop column" calls, so that columns involved in those constraints
    still exist when the constraint is dropped.
    fixes #247

2cdff3d

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Michael Bayer (@zzzeek) wrote:

  • Added a rule for Postgresql to not render a "drop unique" and "drop index"
    given the same name; for now it is assumed that the "index" is the
    implicit one Postgreql generates. Future integration with
    new SQLAlchemy 1.0 features will improve this to be more
    resilient.
    fixes #247

360b8b9

@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot

This comment has been minimized.

sqlalchemy-bot commented Nov 21, 2014

Michael Bayer (@zzzeek) wrote:

OK I found that one and i fixed that also.

@sqlalchemy-bot sqlalchemy-bot added the bug label Nov 27, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment