Closed sqlalchemy-bot closed 6 years ago
Jack Grahl (jwg4) wrote:
Hi, I have found your discussion of this in the docs. This solves my problem, thanks, and sorry I didn't see this earlier.
The link for anyone else who has the same issue: http://alembic.zzzcomputing.com/en/latest/naming.html
Jack Grahl (jwg4) wrote:
This is dealt with in the documentation and solved by setting a naming convention for constraints. http://alembic.zzzcomputing.com/en/latest/naming.html
Michael Bayer (zzzeek) wrote:
yep. sorry sqlalchemy/alembic doesn't like to make assumptions :)
Migrated issue, originally created by Jack Grahl (jwg4)
When adding a foreign key constraint to two pre-existing tables, thus going from:
to
autogenerates a migration where the FK constraint is not given any name like this (full output of
revision --autogenerate
):As can be seen,
create_foreign_key
is called with a name argument ofNone
. This means that the name is left to the default. However, that means that without any warning, the upgrade script will succeed but that the downgrade script will then fail (with postgresql and psycopg2), because there is no name for the foreign key that should be removed.Desired behavior here would be that alembic create a name for the FK constraint and use it as an argument in both
create_foreign_key
and indrop_constraint
so that both upgrade and downgrade work. Failing this, it would be good to have a warning, for example emitted as a comment in the generated code, so that it was clear that a name for the constraint should be chosen by the user and passed to both functions.Thanks a lot for all your hard work on alembic!