在这种情况下，主要问题不仅在于多对多关系，还在于它是一种自我引用的多对多关系。因为automap 只是将映射的类名转换为关系名，所以它构造了相同的名称，例如task_collection，对于关系的两个方向，命名冲突会产生错误。 automap 的这个缺点让人感觉很重要，因为自我参照、多对多关系并不少见。
使用您自己的名称显式添加您想要的关系不会解决问题，因为automap 仍会尝试创建task_collection 关系。为了解决这个问题，我们需要覆盖task_collection。
如果您可以将名称 task_collection 保留为关系的前进方向，我们可以简单地预先定义关系 - 为 backref 指定我们想要的任何名称。如果automap 发现预期的属性已经存在，它将假定该关系已被覆盖，而不是尝试添加它。
这是一个精简的示例，以及用于测试的 sqlite 数据库。
Sqlite 数据库
CREATE TABLE task (
id INTEGER,
name VARCHAR,
PRIMARY KEY (id)
);
CREATE TABLE task_task (
tid1 INTEGER,
tid2 INTEGER,
FOREIGN KEY(tid1) REFERENCES task(id),
FOREIGN KEY(tid2) REFERENCES task(id)
);
-- Some sample data
INSERT INTO task VALUES (0, 'task_0');
INSERT INTO task VALUES (1, 'task_1');
INSERT INTO task VALUES (2, 'task_2');
INSERT INTO task VALUES (3, 'task_3');
INSERT INTO task VALUES (4, 'task_4');
INSERT INTO task_task VALUES (0, 1);
INSERT INTO task_task VALUES (0, 2);
INSERT INTO task_task VALUES (2, 4);
INSERT INTO task_task VALUES (3, 4);
INSERT INTO task_task VALUES (3, 0);
把它放到一个名为setup_self.sql的文件中，我们可以这样做：
sqlite3 self.db < setup_self.sql
Python 代码
from sqlalchemy.ext.automap import automap_base
from sqlalchemy.orm import Session
from sqlalchemy import create_engine
from sqlalchemy import Table, Column, Integer, ForeignKey
from sqlalchemy.orm import relationship
from sqlalchemy.ext.declarative import declarative_base
DeclBase = declarative_base()
task_task = Table('task_task', DeclBase.metadata,
Column('tid1', Integer, ForeignKey('task.id')),
Column('tid2', Integer, ForeignKey('task.id')))
Base = automap_base(DeclBase)
class Task(Base):
__tablename__ = 'task'
task_collection = relationship('Task',
secondary=task_task,
primaryjoin='Task.id==task_task.c.tid1',
secondaryjoin='Task.id==task_task.c.tid2',
backref='backward')
engine = create_engine("sqlite:///self.db")
Base.prepare(engine, reflect=True)
session = Session(engine)
task_0 = session.query(Task).filter_by(name ='task_0').first()
task_4 = session.query(Task).filter_by(name ='task_4').first()
print("task_0.task_collection = {}".format([x.name for x in task_0.task_collection]))
print("task_4.backward = {}".format([x.name for x in task_4.backward]))
结果
task_0.task_collection = ['task_1', 'task_2']
task_4.backward = ['task_2', 'task_3']
使用不同的名称
如果你想使用task_collection以外的名字，你需要使用automap的函数来覆盖集合关系的名字：
name_for_collection_relationship(base, local_cls, referred_cls, constraint)
参数local_cls 和referred_cls 是映射表类的实例。对于自引用的多对多关系，它们都是同一个类。我们可以使用参数来构建一个允许我们识别覆盖的键。
这是此方法的示例实现。
from sqlalchemy.ext.automap import automap_base, name_for_collection_relationship
from sqlalchemy.orm import Session
from sqlalchemy import create_engine
from sqlalchemy import Table, Column, Integer, ForeignKey
from sqlalchemy.orm import relationship
from sqlalchemy.ext.declarative import declarative_base
DeclBase = declarative_base()
task_task = Table('task_task', DeclBase.metadata,
Column('tid1', Integer, ForeignKey('task.id')),
Column('tid2', Integer, ForeignKey('task.id')))
Base = automap_base(DeclBase)
class Task(Base):
__tablename__ = 'task'
forward = relationship('Task',
secondary=task_task,
primaryjoin='Task.id==task_task.c.tid1',
secondaryjoin='Task.id==task_task.c.tid2',
backref='backward')
# A dictionary that maps relationship keys to a method name
OVERRIDES = {
'Task_Task' : 'forward'
}
def _name_for_collection_relationship(base, local_cls, referred_cls, constraint):
# Build the key
key = '{}_{}'.format(local_cls.__name__, referred_cls.__name__)
# Did we have an override name?
if key in OVERRIDES:
# Yes, return it
return OVERRIDES[key]
# Default to the standard automap function
return name_for_collection_relationship(base, local_cls, referred_cls, constraint)
engine = create_engine("sqlite:///self.db")
Base.prepare(engine, reflect=True, name_for_collection_relationship=_name_for_collection_relationship)
请注意，覆盖name_for_collection_relationship 只会更改automap 用于关系的名称。在我们的例子中，这种关系仍然是由Task 预先定义的。但是，覆盖告诉automap 寻找forward 而不是task_collection，它找到并因此停止定义关系。
考虑的其他方法
在某些情况下，如果我们可以覆盖关系名称而不必预先定义实际关系，那就太好了。首先考虑，这应该可以使用name_for_collection_relationship。但是，由于两个原因，我无法让这种方法适用于自我引用的多对多关系。
name_for_collection_relationship 和相关的generate_relationship 被调用两次，对多对多关系的每个方向调用一次。在这两种情况下，local_cls 和 referred_cls 都是相同的，因为它们具有自引用性。此外，name_for_collection_relationship 的其他参数实际上是等效的。因此，我们无法从函数调用的上下文中确定我们要覆盖的方向。
这是问题中更令人惊讶的部分。看来我们甚至不能指望一个方向先于另一个方向发生。换句话说，对name_for_collection_relationship 和generate_relationship 的两次调用非常相似。实际决定关系方向性的参数是constraint，是关系的两个外键约束之一；这些约束从Base.metadata 加载到名为m2m_const 的变量中。问题就在这里。约束以m2m_const 结束的顺序是不确定的，即有时它是一个顺序；其他时候则相反（至少在使用sqlite3 时）。因此，关系的方向性是不确定的。
另一方面，当我们预先定义关系时，以下参数创建了必要的确定性。
primaryjoin='Task.id==task_task.c.tid1',
secondaryjoin='Task.id==task_task.c.tid2',
需要特别注意的是，我实际上试图创建一个解决方案，它只是简单地覆盖关系名称而不预先定义它。它表现出所描述的不确定性。
最后的想法
如果您有合理数量的不经常更改的数据库表，我建议您只使用Declarative Base。设置起来可能需要更多的工作，但它可以让您拥有更多的控制权。