1

私たちのアプリは、is_activeUser Model のフィールドを設定しFalseて、削除されたユーザーを表します。削除されたユーザー ( ) をユーザー テーブルへのすべてのアクセスから
除外するためのベスト プラクティスは何ですか? where is_active=False
次の点を考慮してください
。 1. アプリは既に作成されているため、コードの変更は最小限に留めていただければ幸いです。
2. アプリは:request.userを使用get_object_or_404()し、もちろんも使用User.objectsするため、ソリューションではそれらすべてを考慮する必要があります。


1. プロキシ モデル: コードに多くの変更を加える必要があります。requestとでどのように機能するかわかりませんget_object_or_404()。
2. contribute_to_class: マネージャーをオーバーライドするobjectsために、または単に新しいマネージャーを追加するために使用できますか? 安全ですか？
3. ミドルウェアの変更: これには触れたくありません。私にはリスクが高すぎる。

これを行うエレガントな方法はありますか？

4

1 に答える 1

1

これを行う方法はありません。また、試してはいけません。すべてのアクションをモデル インスタンスの選択に制限する唯一の方法は、デフォルトのクエリセットを制限することです。これにより、除外されたインスタンスが効果的に孤立し、それらに二度とアクセスできなくなります。Djangoのドキュメントでは、この動作に対して明示的に警告しています。

メソッドをオーバーライドget_query_set()して行を除外すると、Django は正しくない結果を返します。そうしないでください。結果をフィルタリングするマネージャーget_query_set()は、自動マネージャーとしての使用には適していません。(私のものを強調)

「自動」マネージャーは、基本的にデフォルトのマネージャーと同じです。これは、関連するフィールド、Django 管理画面、および Django 機構の無数の他の領域で使用されるものです。デフォルトのマネージャを制限すると、全面的にすべてが制限されます。

現在、制限されたクエリセットにすばやくアクセスするためのオプションが他にもあります。それらは単に「自動」ではありません。つまり、すべてを魔法で行うのではなく、それらを使用することを強調する必要があります。ただし、「魔法」は、この点でコア Python テナントの 1 つに違反しています。明示的は暗黙的よりも優れています。デフォルトでクエリセットを制限することUserは、暗黙的なアクションです。クエリセットを手動でフィルタリングする、カスタム マネージャー メソッドを参照する、または のサブクラスを使用することUserは、すべて明示的なアクションであり、結果として好ましいものです。

于 2012-07-05T14:56:52.263 に答える