Миграции SQLAlchemy, генерирующие внешние ключи с разными именами.Как бросить это?

Question

В моей модели данных SQLAlchemy у меня была ссылка от project->customer.Я делаю миграции, и первоначально этот FK был создан с помощью

sa.ForeignKeyConstraint(['customer_id'], ['customers.id'], )

(это было во время той же миграции, которая создала таблицу project, поэтому автоматически сгенерированный down должен просто drop_table).

Теперь я удаляю эту ссылку и, следовательно, убираю это ограничение.Для него автоматически сгенерирована миграция

op.drop_constraint('FK__projects__custom__412EB0B6', 'projects', type_='foreignkey')

Проблема в том, что ограничение не всегда называется .В одной базе данных я проверил ее имя FK__projects__custom__2E1BDC42, в другой - еще одна вещь ... Как правильно удалить ограничение и что вызывает разницу в именах?

Редактировать: Очевидно У меня была возможность назвать ограничение ..., которое, конечно, в документах не упоминается как хорошая и необходимая идея.Итак ... Я знаю, как предотвратить это в будущем, но не знаю, как исправить текущую проблему.

Answer 1

Я закончил тем, что добавил это в свою миграцию

op.execute("""
    DECLARE @fk_project_customer varchar(50);
    SELECT @fk_project_customer = (SELECT name FROM sys.foreign_keys WHERE name LIKE 'FK__projects__custom__%');
    EXEC('ALTER TABLE projects DROP CONSTRAINT "' + @fk_project_customer + '"');
""")

Таким образом, он в основном находит имя ограничения, которое следует за этим шаблоном из sys.foreign_keys, как рекомендовано @Ilja, затем EXEC динамический SQL-запрос от него