Skip to content
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
Closed
Labels
bug

Comments

@sqlalchemy-bot
Copy link

@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
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Nov 21, 2014

Changes by Andrew Magee (@amagee):

  • edited description
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot 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
Copy link
Author

@sqlalchemy-bot 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
Copy link
Author

@sqlalchemy-bot 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
Copy link
Author

@sqlalchemy-bot 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
Copy link
Author

@sqlalchemy-bot sqlalchemy-bot commented Nov 21, 2014

Changes by Michael Bayer (@zzzeek):

  • changed status to closed
@sqlalchemy-bot
Copy link
Author

@sqlalchemy-bot 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant