マネージャ (Manager) とは、Django のモデルに対するデータベースクエリの操作を提供するインターフェイスです。Django アプリケーション内の1つのモデルに対して、Manager は最低でも1つは存在します。
Manager クラスの詳細については、クエリを作成する に書かれています。ここでは、特に、Manager の動作をカスタマイズするモデルのオプションについて説明しています。
デフォルトでは、Django は objects という名前の Manager を各 Django モデルクラスに対して追加します。しかし、もし objects をフィールド名として使いたい場合や、あるいは、Manager に対して objects 以外の名前を使いたい場合には、各モデル単位で好きな名前を付けることができます。あるクラスの Manager の名前を変えるには、そのクラスの上で models.Manager() と書いて、クラス変数を定義します。たとえば、次のように書きます。
from django.db import models\n\n\nclass Person(models.Model):\n # ...\n people = models.Manager()\nこのモデル例を使うと、Person.objects は AttributeError 例外を起こしますが、Person.people.all() と書けば、すべての Person オブジェクトのリストが得られます。
Manager ベースクラスを拡張し、カスタマイズした Manager をモデル内でインスタンス化すれば、特定のモデル用にカスタマイズした Manager を使うことができます。
Manager をカスタマイズしたくなるシチュエーションとしては、たとえば次の2つのような場合が考えられます。1つ目は、Manager に新しいメソッドを追加したい場合、もう1つは、Manager が最初に返す QuerySet を修正したい場合です。
Manager に新しいメソッドを追加するのがふさわしいのは、モデルに対する「テーブルレベル」での操作を追加したい場合です。(「低レベル」の機能、たとえば、あるモデルオブジェクトの1つのインスタンスに作用するような関数の場合には、Manager をカスタマイズするのではなく、モデルメソッド を使ってください。
たとえば、このカスタム Manager は with_counts() メソッドを追加します:
from django.db import models\nfrom django.db.models.functions import Coalesce\n\n\nclass PollManager(models.Manager):\n def with_counts(self):\n return self.annotate(num_responses=Coalesce(models.Count("response"), 0))\n\n\nclass OpinionPoll(models.Model):\n question = models.CharField(max_length=200)\n objects = PollManager()\n\n\nclass Response(models.Model):\n poll = models.ForeignKey(OpinionPoll, on_delete=models.CASCADE)\n # ...\nこの例では、 OpinionPoll.objects.with_counts() を使うことで、 num_responses 属性が付加された OpinionPoll オブジェクトの QuerySet を得ることができます。
カスタムの Manager のメソッドは、どんなオブジェクトを返しても構いません。QuerySet である必要はありません。
注目すべきもう1つの点は、 Manager 内のメソッドではself.modelとすることで、 Manager に紐づいているモデルクラスを取得できることです。
QuerySet を修正するLink to this heading#Manager のベース QuerySet は、すべてのオブジェクトを返します。 たとえば、このモデルの例では...:
from django.db import models\n\n\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n author = models.CharField(max_length=50)\nBook.objects.all() は、データベース内の全ての本を返します。
Manager.get_queryset() メソッドをオーバーライドすることで、 Manager のベース QuerySet を上書きできます。 get_queryset() は、必要な属性を含む QuerySet を返す必要があります。
例えば、次のモデルには 2つ の Manager があります。片方はすべてのオブジェクトを返し、もう片方はRoald Dahlの本のみを返します:
# First, define the Manager subclass.\nclass DahlBookManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(author="Roald Dahl")\n\n\n# Then hook it into the Book model explicitly.\nclass Book(models.Model):\n title = models.CharField(max_length=100)\n author = models.CharField(max_length=50)\n\n objects = models.Manager() # The default manager.\n dahl_objects = DahlBookManager() # The Dahl-specific manager.\nこのモデルの例では、 Book.objects.all() はデータベース上の本を全て返 しますが、 Book.dahl_objects.all() は Roald Dahl の書いた本だけを返しま す。
get_queryset() は QuerySet オブジェクトを返すので、 filter() 、 exclude() 、その他の QuerySet オブジェクトのメソッドを全て使えます。したがって、以下のような文も実行できます。
Book.dahl_objects.all()\nBook.dahl_objects.filter(title="Matilda")\nBook.dahl_objects.count()\nこの例では、同じモデルで複数のマネージャを使用するという、追加の面白いテクニックも紹介しました。一つのモデルに対して、好きなだけ Manager() インスタンスを割り当てることができます。これは、何度も同じコードを書かずにモデルに共通の "フィルタ" を定義するための方法です。
例:
\nclass AuthorManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(role="A")\n\n\nclass EditorManager(models.Manager):\n def get_queryset(self):\n return super().get_queryset().filter(role="E")\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n role = models.CharField(max_length=1, choices={"A": _("Author"), "E": _("Editor")})\n people = models.Manager()\n authors = AuthorManager()\n editors = EditorManager()\nこの例では、Person.authors.all()、Person.editors.all()、Person.people.all() を指定でき、期待通りの結果が得られます。
カスタムの Manager オブジェクトを使う場合、 Django が (モデル内で定義された順番で) 最初に見つけた Manager には特別なステータスがあることに注意してください。Django はクラスで定義された最初の Manager を「デフォルト」の Manager と解釈し、Django の一部の機能 (dumpdata を含む) はそのモデル専用にその Manager を使用します。その結果、get_queryset() をオーバーライドした結果、利用したいオブジェクトを取得できなくなるという事態を避けるために、デフォルトマネージャの選択には注意した方が良いでしょう。
カスタムのデフォルトマネージャは Meta.default_manager_name で指定できます。
たとえば、ジェネリックビューを実装しているサードパーティのアプリで、未知のモデルを扱わなければならないコードを書いている場合、モデルが objects マネージャを持っていると仮定するのではなく、このマネージャ (または _base_manager) を使用してください。
このマネージャは、他のモデルからリレーション先オブジェクトにアクセスするために 使用されます。このような状況では、 Django は、参照されるオブジェクトを すべて 取得できるように、取得するモデルのすべてのオブジェクトを見ることができなければなりません。
\nしたがって、 get_queryset() をオーバーライドして行をフィルタリングしてはいけません。もしそうすれば、 Django は不完全な結果を返します。
QuerySet のメソッド をマネージャから呼び出すLink to this heading#標準の QuerySet のほとんどのメソッドは Manager から直接アクセスできますが、カスタムの QuerySet で定義したメソッドは Manager でも実装する必要があります:
class PersonQuerySet(models.QuerySet):\n def authors(self):\n return self.filter(role="A")\n\n def editors(self):\n return self.filter(role="E")\n\n\nclass PersonManager(models.Manager):\n def get_queryset(self):\n return PersonQuerySet(self.model, using=self._db)\n\n def authors(self):\n return self.get_queryset().authors()\n\n def editors(self):\n return self.get_queryset().editors()\n\n\nclass Person(models.Model):\n first_name = models.CharField(max_length=50)\n last_name = models.CharField(max_length=50)\n role = models.CharField(max_length=1, choices={"A": _("Author"), "E": _("Editor")})\n people = PersonManager()\nこの例では authors() と editors() の両方をマネージャ Person.people から直接呼び出すことができます。
QuerySet のメソッドで、マネージャを生成するLink to this heading#QuerySet と Manager の両方でメソッドを複製する必要がある上記の方法の代わりに、 QuerySet.as_manager() を使用すると、カスタムした QuerySet のメソッドをコピーした Manager のインスタンスを作成できます:
class Person(models.Model):\n ...\n people = PersonQuerySet.as_manager()\nQuerySet.as_manager() によって生成される Manager インスタンスは、前の例の PersonManager とほぼ同じになります。
すべての QuerySet メソッドが Manager レベルで意味を持つわけではありません。例えば、 QuerySet.delete() メソッドが Manager クラスにコピーされることは意図的に防いであります。
メソッドは以下の規則に従ってコピーされます:
\nパブリックメソッドはデフォルトでコピーされます。
プライベートメソッド (アンダースコアで始まるメソッド) は、デフォルトではコピーされません。
queryset_only 属性が False に設定されているメソッドは常にコピーされます。
queryset_only 属性が True に設定されているメソッドはコピーされません。
例:
\nclass CustomQuerySet(models.QuerySet):\n # Available on both Manager and QuerySet.\n def public_method(self):\n return\n\n # Available only on QuerySet.\n def _private_method(self):\n return\n\n # Available only on QuerySet.\n def opted_out_public_method(self):\n return\n\n opted_out_public_method.queryset_only = True\n\n # Available on both Manager and QuerySet.\n def _opted_in_private_method(self):\n return\n\n _opted_in_private_method.queryset_only = False\nfrom_queryset()Link to this heading#高度な使い方をする場合には、カスタムの Manager とカスタムの QuerySet の両方が必要になるかもしれません。この場合、 Manager.from_queryset() を呼び出すことで、カスタム QuerySet メソッドをコピーしたベース Manager の サブクラス を返すことができます:
class CustomManager(models.Manager):\n def manager_only_method(self):\n return\n\n\nclass CustomQuerySet(models.QuerySet):\n def manager_and_queryset_method(self):\n return\n\n\nclass MyModel(models.Model):\n objects = CustomManager.from_queryset(CustomQuerySet)()\n生成されたクラスを変数に格納することもできます:
\nMyManager = CustomManager.from_queryset(CustomQuerySet)\n\n\nclass MyModel(models.Model):\n objects = MyManager()\nDjango がカスタムマネージャと モデルの継承 をどのように扱うかを以下に示します:
\nPython の通常の名前解決順序を使って (子クラスの名前は他を全て上書きし、次に最初の親クラスの名前、 というように) 、基底クラスのマネージャは常に子クラスに継承されます。
モデルやその親クラスでマネージャが宣言されていない場合、Django は自動的に objects マネージャを作成します。
クラスのデフォルトマネージャは Meta.default_manager_name で選択されたマネージャか、モデル上で最初に宣言されたマネージャか、最初の親モデルのデフォルトマネージャです。
これらのルールは、抽象的な基底クラスを経由して、カスタムマネージャのコレクションをモデルのグループにインストールしたい場合でも、デフォルトのマネージャをカスタマイズするために必要な柔軟性を提供します。たとえば、次のような基底クラスがあるとします:
\nclass AbstractBase(models.Model):\n # ...\n objects = CustomManager()\n\n class Meta:\n abstract = True\nこれを子クラスで直接使用した場合、子クラスでマネージャを宣言していなければ objects がデフォルトのマネージャになります:
class ChildA(AbstractBase):\n # ...\n # This class has CustomManager as the default manager.\n pass\nもし AbstractBase を継承して別のデフォルトマネージャを指定したい場合は、子クラスにそのデフォルトマネージャを指定できます:
class ChildB(AbstractBase):\n # ...\n # An explicit default manager.\n default_manager = OtherManager()\n上記では default_manager がデフォルトです。 objects マネージャは継承されているのでまだ使用可能ですが、デフォルトでは使用されません。
最後に、この例では AbstractBase のデフォルトを使用しつつ、子クラスに追加のマネージャを追加したいとします。 新しいマネージャを子クラスに直接追加することはできません。デフォルトをオーバーライドすることになり、抽象基底クラスのすべてのマネージャを明示的にインクルードする必要があるからです。解決策としては、追加のマネージャを別の基底クラスに置き、それをデフォルトクラスの 後の 継承階層に含めることです:
class ExtraManager(models.Model):\n extra_manager = OtherManager()\n\n class Meta:\n abstract = True\n\n\nclass ChildC(AbstractBase, ExtraManager):\n # ...\n # Default manager is CustomManager, but OtherManager is\n # also available via the "extra_manager" attribute.\n pass\n抽象モデル上でカスタムマネージャを 定義 することはできますが、抽象モデルを使ってメソッドを 呼び出す ことはできないことに注意してください。 つまり:
\nClassA.objects.do_something()\n上記は有効なコードですが、:
\nAbstractBase.objects.do_something()\n上記では例外が発生します。 これはマネージャがオブジェクトのコレクションを管理するためのロジックをカプセル化することを想定しているためです。抽象オブジェクトのコレクションを持つことはできないので、それらを管理することは意味がありません。抽象モデルに適用される機能がある場合、その機能は抽象モデルの staticmethod か classmethod に置くべきです。
\nカスタムマネージャにどのような機能を追加するにしても、マネージャインスタンスの浅いコピーを作成できることが必須です:
\n>>> import copy\n>>> manager = MyManager()\n>>> my_copy = copy.copy(manager)\nDjango は特定のクエリ中にマネージャオブジェクトの浅いコピーを作成します。マネージャがコピーできない場合、これらのクエリは失敗します。
\nほとんどのカスタムマネージャでは問題にならないでしょう。単純なメソッドを Manager に追加するだけであれば、 Manager のインスタンスをコピー不可能にすることはまずありません。しかし、オブジェクトの状態をコントロールする Manager オブジェクトの __getattr__ やその他のプライベートメソッドをオーバーライドする場合は、 Manager のコピー機能に影響を与えないようにする必要があります。