Meta オプションLink to this heading#このドキュメントでは、モデル内部の class Meta 内でモデルに与えられる、すべての可能な メタデータオプション を説明します。
Meta オプションLink to this heading#abstractLink to this heading#abstract = True の場合、このモデルは 抽象基底クラス になります。
app_labelLink to this heading#モデルが INSTALLED_APPS でアプリケーションの外部で定義されている場合、どのアプリケーションに属するかを宣言する必要があります：
app_label = "myapp"\nモデルを app_label.object_name または app_label.model_name という形式で表現したい場合は、それぞれ model._meta.label または model._meta.label_lower を使用します。
base_manager_nameLink to this heading#モデルの _base_manager に使用するマネージャの属性名、例えば 'objects' です。
db_tableLink to this heading#モデルに使用するデータベーステーブルの名前：
\ndb_table = "music_album"\n手間を省くために、Django はモデルクラスとそれを含むアプリの名前から、データベーステーブルの名前を自動的に生成します。モデルのデータベーステーブル名は、モデルの "app label" (manage.py startapp で使った名前) とモデルのクラス名をアンダースコアでつないで作ります。
例えば、アプリ bookstore (manage.py startapp bookstore で作成) がある場合、class Book として定義されたモデルは bookstore_book という名前のデータベーステーブルを持ちます。
データベーステーブル名を上書きするには、 class Meta の db_table パラメータを使用します。
データベースのテーブル名が SQL の予約語だったり、 Python の変数名では許されない文字（特にハイフン）を含んでいたりしても大丈夫です。Django は裏でカラム名とテーブル名をクォート処理します。
\n\n\ndb_table_commentLink to this heading#このモデルに使うデータベーステーブルのコメントです。あなたの Django コードを見ていない、直接データベースにアクセスできる人のために、 データベーステーブルをドキュメント化するのに便利です。たとえば以下のようにします：
\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n answer = models.TextField()\n\n class Meta:\n db_table_comment = "Question answers"\ndb_tablespaceLink to this heading#このモデルに使用する データベーステーブル空間 の名前です。デフォルトはプロジェクトの DEFAULT_TABLESPACE 設定です。バックエンドがテーブル空間をサポートしていない場合、このオプションは無視されます。
default_manager_nameLink to this heading#モデルの _default_manager に使用するマネージャの名前。
get_latest_byLink to this heading#モデル内のフィールド名またはフィールド名のリスト。通常は DateField, DateTimeField, IntegerField です。これはモデル Manager の latest() と earliest() メソッドで使用するデフォルトのフィールドを指定します。
実装例:
\n# Latest by ascending order_date.\nget_latest_by = "order_date"\n\n# Latest by priority descending, order_date ascending.\nget_latest_by = ["-priority", "order_date"]\n詳しくは latest() のドキュメントを参照してください。
managedLink to this heading#デフォルトは True です。つまり、 Django は migrate やマイグレーションの一部として適切なデータベーステーブルを作成し、 flush 管理コマンドの一部として削除します。つまり、 Django はデータベーステーブルのライフサイクルを 管理 します。
False の場合、このモデルに対してデータベーステーブルの作成、変更、削除の操作を行いません。これは、モデルが既存のテーブルや他の方法で作成されたデータベースビューを表す場合に便利です。これは managed=False の場合の 唯一の 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。
Adding an automatic primary key field to the model if you don't\ndeclare it. To avoid confusion for later code readers, it's\nrecommended to specify all the columns from the database table you\nare modeling when using unmanaged models.
managed=False のモデルが ManyToManyField を含み、それが別の管理対象外モデルを指している場合、多対多の結合のための中間テーブルも作成されません。しかし、1つの管理モデルと1つの管理対象外モデル間の中間テーブルは 作成 されます。
このデフォルトの動作を変更する必要がある場合は、(managed を必要に応じて設定した) 明示的なモデルとして中間テーブルを作成し、 ManyToManyField.through 属性を使用してカスタムモデルとのリレーションを作成します。
managed=False のモデルを含むテストでは、テストのセットアップの一部として正しいテーブルが作成されるようにする必要があります。
モデルクラスの Python レベルでの動作を変更したい場合、 managed=False を使って既存のモデルのコピーを作成することもできます。しかし、その場合はもっと良い方法があります。 プロキシモデル です。
order_with_respect_toLink to this heading#このオブジェクトを指定されたフィールドに対してソート可能にします。通常は ForeignKey です。これは、リレーション先オブジェクトを親オブジェクトに対してソート可能にするために使用できます。例えば、 Answer と Question オブジェクトにリレーションがあり、質問には複数の答えがあり、答えの順番が重要である場合、次のようにします：
from django.db import models\n\n\nclass Question(models.Model):\n text = models.TextField()\n # ...\n\n\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n # ...\n\n class Meta:\n order_with_respect_to = "question"\norder_with_respect_to が指定されている場合、リレーション先オブジェクトの順序を取得・設定するための2つのメソッドが追加されます。 get_RELATED_order() と set_RELATED_order() で、 RELATED は小文字のモデル名です。たとえば、ある Question オブジェクトが複数の Answer オブジェクトにリレーションしているとすると、返されるリストにはリレーション先の Answer オブジェクトの主キーが含まれます：
>>> question = Question.objects.get(id=1)\n>>> question.get_answer_order()\n[1, 2, 3]\nQuestionオブジェクトのリレーション先の Answer オブジェクトの順番は、 Answer の主キーのリストを渡すことで設定できます：
>>> question.set_answer_order([3, 1, 2])\nリレーション先オブジェクトには get_next_in_order() と get_previous_in_order() というメソッドもあり、これらのオブジェクトに適切な順番でアクセスできます。 Answer オブジェクトが id で並べられていると仮定すると、下記のようになります：
>>> answer = Answer.objects.get(id=2)\n>>> answer.get_next_in_order()\n<Answer: 3>\n>>> answer.get_previous_in_order()\n<Answer: 1>\norderingLink to this heading#オブジェクトのリストを取得するときに使用する、オブジェクトのデフォルトの順序：
\nordering = ["-order_date"]\nこれは文字列やクエリ式のタプルまたはリストです。各文字列はフィールド名で、オプションのプレフィックス "-" は降順を表します。先頭の "-" がないフィールドは昇順に並びます。ランダムに並び替えたい場合は、文字列 "?" を使用します。
\n例えば、 pub_date フィールドで昇順にソートするには、次のようにします：
ordering = ["pub_date"]\npub_date の降順でソートするには、次のようにします：
ordering = ["-pub_date"]\npub_date の降順でソートし、 author の昇順でソートするには、次のようにします：
ordering = ["-pub_date", "author"]\nクエリ式 を使うこともできます。 author の昇順で並び替え、null値を最後にソートしたい場合、これを使います:
from django.db.models import F\n\nordering = [F("author").asc(nulls_last=True)]\npermissionsLink to this heading#このオブジェクトを作成するときに permissions テーブルに入力する追加のパーミッション。追加、変更、削除、表示のパーミッションはそれぞれのモデルに対して自動的に作成されます。この例では can_deliver_pizzas という追加のパーミッションを指定しています：
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]\nこれは (permission_code, human_readable_permission_name) の形式の2値タプルのリストまたはタプルです。
default_permissionsLink to this heading#デフォルトは ('add', 'change', 'delete', 'view') です。このリストはカスタマイズできます。例えば、アプリがデフォルトのパーミッションを必要としない場合は、空のリストを指定します。暗黙的にパーミッションが作成されるのを防ぐには、 migrate によってモデルが作成される前に、モデルに指定する必要があります。
proxyLink to this heading#proxy = True の場合、他のモデルをサブクラス化したモデルは プロキシモデル として扱われます。
required_db_featuresLink to this heading#現在の接続が持つべきデータベースの機能のリストで、このリストに基づいてモデルがマイグレーションフェーズで考慮されます。たとえば、このリストを ['gis_enabled'] に設定すると、そのモデルはGISが有効なデータベース上でのみ同期されます。これは、複数のデータベースバックエンドでテストする際に、一部のモデルをスキップするのにも便利です。作成されるかどうかわからないモデル間のリレーションは避けてください。ORMはこれを処理しません。
required_db_vendorLink to this heading#このモデルが特定する、サポートされているデータベース・ベンダーの名前。現在の組み込みベンダー名は sqlite, postgresql, mysql, oracle です。この属性が空ではなく、現在の接続ベンダーがこの属性と一致しない場合、モデルは同期されません。
select_on_saveLink to this heading#Determines if Django will use the pre-1.6\ndjango.db.models.Model.save() algorithm. The old algorithm\nuses SELECT to determine if there is an existing row to be updated.\nThe new algorithm tries an UPDATE directly. In some rare cases the\nUPDATE of an existing row isn't visible to Django. An example is the\nPostgreSQL ON UPDATE trigger which returns NULL. In such cases the\nnew algorithm will end up doing an INSERT even when a row exists in\nthe database.
通常、この属性を設定する必要はありません。デフォルトは False です。
See django.db.models.Model.save() for more about the old and\nnew saving algorithm.
indexesLink to this heading#モデルに定義したい インデックス のリストです：
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n first_name = models.CharField(max_length=100)\n last_name = models.CharField(max_length=100)\n\n class Meta:\n indexes = [\n models.Index(fields=["last_name", "first_name"]),\n models.Index(fields=["first_name"], name="first_name_idx"),\n ]\nunique_togetherLink to this heading#組み合わせが一意でなければならないフィールドのリストを指定します。
\nunique_together = [["driver", "restaurant"]]\nこれは、一緒に考えたときに一意でなければならないリストのリストです。Django の管理画面で使われ、データベースレベルで強制されます (つまり、 CREATE TABLE ステートメントに適切な UNIQUE ステートメントが含まれます)。
利便性のために、unique_together は1つのフィールドセットしかないときは1つのリストにできます：
unique_together = ["driver", "restaurant"]\nManyToManyField を unique_together に含めることはできません（それが何を意味するのかさえ不明です！）。ManyToManyField に関連する一意性を検証する必要がある場合は、シグナルを使うか、明示的な through モデルを使用してみてください。
制約に違反したときにモデル検証中に発生する ValidationError は unique_together エラーコードを持ちます。
constraintsLink to this heading#モデルに定義したい 制約 のリスト：
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n age = models.IntegerField()\n\n class Meta:\n constraints = [\n models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),\n ]\nverbose_nameLink to this heading#人間が読めるオブジェクトの名前（単数形）：
\nverbose_name = "pizza"\n指定されない場合、 Django はクラス名を小文字にして使います。 CamelCase は camel case になります。
verbose_name_pluralLink to this heading#オブジェクトの名前の複数形：
\nverbose_name_plural = "stories"\n指定されない場合、 Django は verbose_name + "s" を使用します。
Meta 属性Link to this heading#labelLink to this heading#オブジェクトの表現。app_label.object_name を返します。例： 'polls.Question'
label_lowerLink to this heading#モデルの表現。app_label.model_name' を返します。例： 'polls.question'