最終的にリリースする予定の Python Django モデルのコンテキストで、興味深い設計上の決定を行う必要があります。
クラスは ApprovalRequest をモデル化します。これは、別のユーザー グループによって投票される可能性があるユーザーによって要求された質問/要求を表します。これは、上訴することもできます。その後、「より高いレベルの」グループなどによって再び投票することができます。
私は次のモデルツリーに相当するものを持っています:
- ApprovalRequest (単一リクエスト)
- ユーザーがアクションを要求しています
- アクションタイプ* / 追加データ
- ApprovalStage (場合によっては投票の多くの段階、時間的に順次)
- 関連する承認申請
- 投票の種類 (単純過半数、必要な 1 票など)
- 投票できるユーザー*
- ApprovalVote (1 人の投票者による 1 票)
- 関連する承認段階
私の最初の質問は、「アクション タイプ」に関するものです。誰でも使える再利用可能なモジュールにしたいので、イベントが発生したときにシグナルを発するようにしたいです。ただし、このモデルは、モデレーション、ユーザー プロモーション、ユーザー禁止の再審査請求の決定など、多くの場合に機能します。そのため、ある種の「タイプ」パラメーターが必要です。OOP 設計でこれを解決する古典的な方法は、サブクラスを作成してカスタム アクションを持たせることですが、これは問題ありませんが、Django (特に) には、DB から「正しい」サブクラスを取得する簡単な方法がありません。たとえば、組み込みのモデル継承を使用すると、メインの ApprovalRequest db テーブルと、各子のデータ用の N 個の追加 db テーブルが存在します。
ここで最初に考えたのは、サブクラス「レジストリ」を作成することです。これにより、タイプ フィールドに一意の ID が割り当てられるため、タイプ固有のアクションを実行する必要がある場合に、登録済みのタイプに確実にダウンキャストできます。これにより、サブクラスはサブクラスの (プロジェクト全体の) id を選択することを余儀なくされ、一般的に洗練されていないように見えます。
2 つ目の質問は、「投票できるユーザー」に関するものです。これらの ApprovalRequest オブジェクトのほとんどは、たとえば Django 管理者によってではなく、実際にはコードによって作成されると思います。次のアクションが発生するとします。
- ユーザーがプロモーション (またはその他のアクション) をリクエストする
- ApprovalRequest オブジェクトが作成され、特定のコード依存グループ (つまり、複雑なクエリセット) に一致するすべてのユーザーが投票できるように指定されます。
- ApprovalRequest に対してアクションが実行されないまま時間が経過する
- 10 人の新しいユーザーが複雑なクエリセットの基準を満たしています (つまり、ApprovalRequest が作成されていれば、これらのユーザーも投票グループの一部になります)。
- これらの新しいユーザーが投票できるようにしたい
問題は、多かれ少なかれ、この複雑なクエリセットを安全な方法で保存するにはどうすればよいかということです。この作業を型に基づいてサブクラスに委譲することはできますが、それは洗練されていないように思えます。どうにかしてクエリセットをデータベースに保存することもできますが、それは少しハックなようです。選択する標準的なルートは何ですか?
これらの質問についてアドバイスをいただければ幸いです。