You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
When using alembic revision --autogenerate, alembic wants to add this index to the database, even though it already exists.
The index is correctly detected by Inspector.get_indexes, but then removed from the conn_indexes list by MySQLImpl.correct_for_autogen_constraints. This method removes all indexes where the name is equal to the first column. The result is that the index is created in the upgrade method of the migration:
sqlalchemy.exc.OperationalError: (OperationalError) (1061, "Duplicate key name 'account_id'") 'CREATE INDEX account_id ON account_event (account_id)' ()
It would be ok if _compare_indexes_and_uniques ignores these indexes, but it has to do so on the metadata side as well as the database side. Currently it pretends the indexes on the database don't exist, and tries to add them, which gives an error.
The text was updated successfully, but these errors were encountered:
OK I guess what we can do is for those indexes we found on the reflected side, remove the same ones from the metadata side as well. that would allow some support for detecting an "add" of these indexes. As you can see in the comment, MySQL has implicit column-named indexes placed on FK columns anyway, your approach hasn't run into problems with that ?
This releases' "autogenerate index detection" bug, when a MySQL table
includes an Index with the same name as a column, autogenerate reported
it as an "add" even though its not; this is because we ignore reflected
indexes of this nature due to MySQL creating them implicitly. Indexes
that are named the same as a column are now ignored on
MySQL if we see that the backend is reporting that it already exists;
this indicates that we can still detect additions of these indexes
but not drops, as we cannot distinguish a backend index same-named
as the column as one that is user generated or mysql-generated.
fixes Autogenerate wants to add existing indexes #202
OK so this will no longer report an "add" when there isn't one, and it will still detect an actual "add" of such an index. We just can't detect when such an index is "dropped" because when we see it on the backend, we don't know if that index is an implicitly generated one or not.