In the alembic documentation, there is an entire page devoted to naming
constraints:
http://alembic.readthedocs.org/en/latest/naming.html
So I assumed that if constraints had a naming scheme defined, then
those names would be detected if changed.
My specific use case is as follows. My naming scheme for foreign keys is:
"fk": "fk_%(table_name)s_%(column_0_name)s",
1) I changed the __tablename__'s and class names of some tables
to add a prefix to each.
2) I updated the ForeignKey()'s to point to the new table names.
3) I then ran alembic autogenerate, which produced drop/create
commands for my tables, and some drop/creates for
constraints in non-renamed, but affected tables.
I manually converted these scripts to use op.rename_table()
and removed all the rest.
4) I ran alembic upgrade head, which renamed the tables, but
not the constraints, as expected.
5) Here I expected another alembic revision --autogenerate
to give me only the constraint changes, but it said
that nothing changed.
During further experiments, if I removed a ForeignKey(), alembic
produced an autogenerate script that used the old constraint name
in the drop_constraint() command.
If I then added the foreign key back, it used the *new* constraint
name based on the new table name.
Obviously I need to be really careful with renames, but this behaviour
was somewhat unexpected. It appears that alembic is already kinda smart
about matching a table's constraint to the model, even if the names
don't match. Could it also be made smart enough to detect when
a constraint "rename" is needed? If I go to all the trouble to make sure
my constraints are named properly, it would be nice if alembic helped
me make sure those names were actually up to date. :-)
Thanks,
- Chris
--
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.
