Python（django）通用模塊開發-在數據庫中存儲動態查詢集？ 模型繼承

Question

在要最終發布的Python Django模型的背景下，我有一個有趣的設計決定。

這些類對ApprovalRequest進行建模，該ApprovalRequest表示用戶提出的一個問題/請求，可以由另一個用戶組投票，也可以對其進行上訴，然后可以由“更高級別”的組再次投票，等等。

我對以下模型樹有什么看法：

• ApprovalRequest（單個請求）
  • 用戶請求動作
  • 動作類型* /其他數據
• ApprovalStage（可能是投票的多個階段，按時間順序）
  • 關聯的批准請求
  • 投票類型（多數票，需要一票，等等）
  • 可以投票的用戶*
• 批准投票（一票，由一個選民投票）
  • 相關批准階段

我的第一個問題是關於“動作類型”的。 因為我的意圖是使它成為任何人都可以使用的可重用模塊，所以我希望它在事件發生時發出信號。 但是，此模型適用於多種情況-審核，提升用戶，禁止用戶上訴等。因此，需要某種“類型”參數。 在OOP設計中解決此問題的經典方法是允許創建子類並具有自定義操作，這很好，但是Django（尤其是Django）沒有簡單的方法來從數據庫中獲取“正確的”子類。 例如，使用內置的模型繼承，每個孩子的數據將有一個主ApprovalRequest數據庫表和N個其他數據庫表。

我最初的想法是創建一個子類“注冊表”，該子類將為我的類型字段分配一個唯一的ID，這樣當我需要執行特定於類型的操作時，我可以可靠地將其下垂到已注冊的類型。 這將迫使子類為其子類選擇一個（項目范圍內的）id，並且通常看起來很不雅致。

我的第二個問題與“可以投票的用戶”有關。 我希望大多數ApprovalRequest對象實際上是由代碼創建的，而不是通過Django admin創建的。 假設發生以下動作：

1. 用戶請求升級（或其他操作）
2. 創建ApprovalRequest對象，指定與某個特定於代碼相關的組（即復雜查詢集）匹配的所有用戶都可以投票
3. 時間流逝，未對ApprovalRequest采取任何措施
4. 現在有10個新用戶符合復雜查詢集的條件（也就是說，如果現在創建了ApprovalRequest，這些用戶也將成為投票組的一部分）
5. 我希望這些新用戶能夠投票

問題是或多或少，我如何以安全的方式存儲此復雜的查詢集？ 我可以將這項工作委托給基於類型的子類，但這似乎很不雅致。 我可以嘗試以某種方式將queryset存儲在數據庫中 ，但這似乎有點hacky。 選擇的標准路線是什么？

感謝您對這些問題的任何建議。

Answer 1

Django中已經存在為模型分配唯一ID的機制： https : //docs.djangoproject.com/en/dev/ref/contrib/contenttypes/