在数据库中存储动态查询集的Python（Django）通用模块开发？模型继承人

Question

在我计划最终发布的pythondjango模型的上下文中，我有一个有趣的设计决策。你知道吗

这些类对ApprovalRequest进行建模，ApprovalRequest表示一个用户请求的问题/请求，该问题/请求可以由另一个用户组投票，也可以上诉，然后由“更高级别”的组再次投票，等等

我有以下模型树：

• 批准请求（单个）
  • 请求操作的用户
  • 动作类型*/附加数据
• 批准（可能是投票的多个阶段，按时间顺序）
  • 相关批准请求
  • 投票类型（简单多数、需要一票等）
  • 可以投票的用户*
• 赞成票（由一个投票人投的一票）
  • 相关批准

我的第一个问题是关于“动作类型”。因为我的目的是让它成为一个任何人都可以使用的可重用模块，所以我希望它在事件发生时发出信号。然而，这个模型适用于许多事情-适度，用户推广，用户禁止上诉决定等，因此，需要某种类型的“类型”参数。在OOP设计中解决这个问题的一个经典方法是允许创建子类并进行自定义操作，这很好，但是Django（尤其是）没有简单的方法从DB中获取“正确”的子类。例如，使用内置模型继承，每个子级的数据将有一个主ApprovalRequest db表和N个附加db表。你知道吗

我最初的想法是创建一个子类“registry”，它将为我的类型字段分配一个唯一的id，这样当我需要执行特定于类型的操作时，我就可以可靠地向下转换到已注册的类型。这将迫使子类为它们的子类选择一个（项目范围的）id，并且通常看起来不美观。你知道吗

我的第二个问题与“可以投票的用户”有关。我希望大多数ApprovalRequest对象实际上是由代码创建的，而不是通过Django管理员创建的。假设发生以下操作：

1. 用户请求提升（或其他操作）
2. ApprovalRequest对象被创建，指定所有匹配特定代码相关组（即复杂查询集）的用户都可以投票
3. 时间流逝，没有对批准请求采取任何行动
4. 现在有10个新用户符合复杂查询集的标准（也就是说，如果现在创建了ApprovalRequest，那么这些用户也将是投票组的一部分）
5. 我希望这些新用户能够投票

问题是，或多或少，如何以安全的方式存储这个复杂的查询集？我可以将这项工作委托给基于类型的子类，但这似乎不够优雅。我可以试试storing the queryset in the database somehow，但这似乎有点不太对劲。选择的标准路线是什么？你知道吗

谢谢你对这些问题的建议。你知道吗

Answer 1

Django中已经有了为模型分配唯一id的机制：https://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/