SQLAlchemy 迁移生成具有不同名称的外键。如何丢弃这些？答案

【问题标题】：SQLAlchemy migrations generating foreign keys with different names. How to drop these?SQLAlchemy 迁移生成具有不同名称的外键。如何丢弃这些？
【发布时间】：2019-05-22 09:19:45
【问题描述】：

在我的 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，在另一件事中...如何正确删除约束以及导致名称差异的原因是什么？

编辑： 显然I had the option to name the constraint ...文档当然没有提到这是一个好的和必要的想法。所以...我知道将来如何防止这种情况，但不知道如何解决当前问题。

【问题讨论】：

您使用的是哪个 DBMS？ mssql?
@IljaEverilä Sql Server
也许您可以在迁移期间查询sys.foreign_keys 以找出约束的实际名称？

标签： python sqlalchemy alembic sqlalchemy-migrate

【解决方案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 + '"');
""")

所以它基本上按照@Ilja 的建议从sys.foreign_keys 中找到遵循此模式的约束名称，然后从EXEC 中找到一个动态sql 查询

【讨论】：