django 模型：如何克服“通过”ManyToMany 选项限制

Posted 2023-02-23

【中文标题】django 模型：如何克服“通过”ManyToMany 选项限制

【英文标题】：django models: how to overcome 'through' ManyToMany option limitation

【发布时间】：2013-04-22 05:30:05

【问题描述】：

我正在开发一个允许用户自己创建和管理用户组的应用程序。

问题是我想存储哪个用户向任何组添加了新成员。

这些是我目前的模型：

class UserManagedGroup(Group):

    leader = models.ForeignKey(User, verbose_name=_('group leader'), related_name='leaded_groups')
    members = models.ManyToManyField(User, verbose_name=_('members'), through='Membership',
                                     related_name='managed_groups')

class Membership(models.Model):

    user = models.ForeignKey(User, related_name='memberships')
    group = models.ForeignKey(UserManagedGroup, related_name='memberships')
    info = models.OneToOneField('MembershipInfo', verbose_name=_('membership information'))

    class Meta:
        unique_together = ['user', 'group']

class MembershipInfo(models.Model):

    date_added = models.DateField(_('date added'), auto_now_add=True)
    made_member_by = models.ForeignKey(User, verbose_name=_('user who made him a member'))
    membership_justification = models.TextField(_('membership justification'), blank=True, default='')


@receiver(signals.post_delete, sender=Membership)
def delete_membership_info(sender, instance, *args, **kwargs):
    if instance.info.pk:
        instance.info.delete()

如您所见，我有一个愚蠢的 MembershipInfo 模型，由于其字段的性质，它更适合与 Membership 合并。此外，MembershipInfos 的生命与它的Membership 绑定在一起（这就是我必须创建这个 post_delete 信号连接的原因）。

因此我无法合并它们：

您的中间模型必须包含一个 - 并且只有一个 - 目标模型的外键（在我们的示例中为 Person）。如果您有多个外键，则会引发验证错误。

（在我的情况下，我不能对用户使用 2 个外键）

现在，这确实有效，但我不喜欢它。它使Membership 实例的创建变得乏味，因为我必须始终首先创建MembershipInfo 实例。此外，2 个查询而不是 1 个。

问题将 2 个外键存储到绑定到我的成员关系的同一模型 (User) 的最佳方式。

【参考方案1】：

我刚刚解决了一个类似的问题，其中包括一个中间模型，其中两个外键指向同一个目标。这是我的系统的样子：

class Node(models.Model):
    receivers = models.ManyToManyField('self', through='Connection',  related_name='senders',  symmetrical=False)

class Connection(models.Model):
    sender = models.ForeignKey(Node, related_name='outgoing')
    receiver = models.ForeignKey(Node, related_name='incoming')

我认为这说明了在中间模型中对同一目标使用两个外键的主要要求。也就是说，模型应该有一个ManyToManyField，目标是'self'（递归多对多），属性through指向中间模型。我认为也有必要为每个外键分配一个唯一的related_name。 symmetrical=False 参数适用于递归关系，如果您希望它们是单向的，例如Node1 向Node2 发送信号，但Node2 不一定向Node1 发送信号。有必要使用symmetrical=False 定义关系，以便递归多对多使用自定义“通过”模型。如果您想使用自定义“通过”模型创建对称递归多对多，可以在here 找到建议。

我发现所有这些相互关系都相当混乱，所以我花了一些时间来选择实际捕获代码正在做什么的合理模型属性和相关名称。为了阐明这是如何工作的，如果我有一个节点对象 N，调用 N.receivers.all() 或 N.senders.all() 分别返回从 N 接收数据或向 N 发送数据的其他节点集。调用N.outgoing.all() 或N.incoming.all() 通过related_names 访问Connection 对象本身。请注意，senders 和 receivers 可以在 ManyToManyField 中交换仍然存在一些歧义，并且代码同样可以正常工作，但方向相反。我通过检查“发送者”是否实际发送给“接收者”或反之亦然的测试用例得出上述结论。

在您的情况下，将两个外键都定位到 User 会增加复杂性，因为如何直接将递归 ManyToManyField 添加到 User 并不明显。我认为自定义用户模型的首选方法是通过一个通过 OneToOneField 连接到用户的代理来扩展它。这可能不令人满意，就像使用 MembershipInfo 扩展 Membership 不令人满意一样，但它至少允许您轻松地向 User 模型添加进一步的自定义。

所以对于你的系统，我会尝试这样的事情（未经测试）：

class Member(models.Model):
    user = models.OneToOneField(User, related_name='member')
    recruiters = models.ManyToManyField('self', through = 'Membership',  related_name = 'recruits',  symmetrical=False)
    other_custom_info = ... 

class UserManagedGroup(Group):
    leader = models.ForeignKey(Member, related_name='leaded_groups')
    members = models.ManyToManyField(Member, through='Membership', related_name='managed_groups')

class Membership(models.Model):
    member = models.ForeignKey(Member, related_name='memberships')
    made_member_by = models.ForeignKey(Member, related_name='recruitments')
    group = models.ForeignKey(UserManagedGroup, related_name='memberships')

    date_added = ...
    membership_justification = ...

递归字段应该是不对称的，因为 Member1 招募 Member2 不应该也意味着 Member2 招募了 Member1。我更改了一些属性以更清楚地传达关系。您可以在任何其他使用 User 的地方使用代理 Member，因为如果您需要访问 user 对象，您始终可以访问 Member.user。如果这按预期工作，您应该能够对给定的成员 M 执行以下操作：

M.recruiters.all() -> set of other members that have recruited M to groups
M.recruits.all() -> set of other members that M has recruited to groups
M.leaded_groups.all() -> set of groups M leads
M.managed_groups.all() -> set of groups of which M is a member
M.memberships.all() -> set of Membership objects in which M has been recruited
M.recruitments.all() -> set of Membership objects in which M has recruited someone

对于 G 组，

G.memberships.all() -> set of Memberships associated with the group

我认为这应该可以工作并提供比单独的 MembershipInfo 模型“更干净”的解决方案，但它可能需要一些调整，例如检查递归字段的方向以确保招聘人员是招募新兵，反之亦然。

编辑：我忘记将 Member 模型链接到 User 模型。可以这样完成：

def create_member(member, instance, created, **kwargs):
    if created:
        member, created = Member.objects.get_or_create(user=instance)

post_save.connect(create_member, member=User)

注意 create_member 不是 Member 的方法，而是在定义 Member 之后调用。通过这样做，每当创建用户时都应该自动创建一个成员对象（如果您想在不初始化成员字段的情况下添加用户，您可能需要将成员字段设置为 null=True 和/或空白=True）。

【讨论】：

您好，谢谢您的回答。我看到的问题是您仍然有 2 ForeignKeys 到同一模型。如果模型是 Node，User 或 Member 应该没有区别。文档这样说：您的中间模型必须包含一个 - 并且只有一个 - 目标模型的外键（在您提出的解决方案中这将是 Member）。如果您有多个外键，则会引发验证错误。

如果我的模型与 through 一起使用并且该模型有 2 个对同一模型的引用，则我的 syncdb 不起作用。也许您的案例之所以有效，是因为与self 有关系。我不知道...

是的，目标模型必须有一个递归的 ManyToManyField（与self 的关系）才能工作。我在设置我的模型时收到了同样的错误，但是尽管有两个外键指向同一个模型，它们现在仍然可以工作。您可以查看更多示例 here 和 here。

如果你仔细想想，这就是有两个指向同一个模型的外键的真正含义：成员通过成员资格与其他成员有某种关系。因此，即使您不提供自定义 through 模型，您也应该定义与 self 的关系（如果不提供，将创建一个具有两个外键成员的通用模型）。

【参考方案2】：

我看到的最简单的方法是从您的 UserManagedGroup 中删除 ManyToMany 字段并合并 Membership 和 MembershipInfo。

您也可以使用 entry_set 字段访问您的成员。