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 の場合の 唯一の 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。
主キーフィールドを宣言しない場合、モデルに自動的に主キーフィールドを追加します。 後でコードを読む人の混乱を避けるために、管理対象外のモデルを使うときには、モデル化しているデータベーステーブルのすべてのカラムを指定することをお勧めします。
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#Django が 1.6 より前の django.db.models.Model.save() アルゴリズムを使うかどうかを決定します。古いアルゴリズムでは、 SELECT を使って、更新する既存の行があるかどうかを判断します。新しいアルゴリズムは UPDATE を直接試みます。まれに、既存の行の UPDATE が Django から見えない場合があります。たとえば、PostgreSQL の ON UPDATE トリガーは NULL を返します。このような場合、新しいアルゴリズムは、データベースに行が存在しても、 INSERT を実行してしまいます。
通常、この属性を設定する必要はありません。デフォルトは False です。
新旧の保存アルゴリズムについては django.db.models.Model.save() を参照してください。
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 エラーコードを持ちます。
index_togetherLink to this heading#一緒にインデックスが作成されるフィールド名のセットです：
\nindex_together = [\n ["pub_date", "deadline"],\n]\nこのフィールドのリストは一緒にインデックスが作成されます（つまり、適切な CREATE INDEX ステートメントが発行されます）。
利便性のために、index_together は1つのフィールドセットしかない場合は1つのリストにすることができます：
index_together = ["pub_date", "deadline"]\nconstraintsLink 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(check=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'