モデルの Meta オプション

このドキュメントでは、モデル内部の class Meta 内でモデルに与えられる、すべての可能な メタデータオプション を説明します。

利用可能な Meta オプション

abstract

Options.abstract

abstract = True の場合、このモデルは 抽象基底クラス になります。

app_label

Options.app_label

モデルが INSTALLED_APPS でアプリケーションの外部で定義されている場合、どのアプリケーションに属するかを宣言する必要があります：

app_label = "myapp"

モデルを app_label.object_name または app_label.model_name という形式で表現したい場合は、それぞれ model._meta.label または model._meta.label_lower を使用します。

base_manager_name

Options.base_manager_name

モデルの _base_manager に使用するマネージャの属性名、例えば 'objects' です。

db_table

Options.db_table

モデルに使用するデータベーステーブルの名前：

db_table = "music_album"

テーブル名

手間を省くために、Django はモデルクラスとそれを含むアプリの名前から、データベーステーブルの名前を自動的に生成します。モデルのデータベーステーブル名は、モデルの "app label" (manage.py startapp で使った名前) とモデルのクラス名をアンダースコアでつないで作ります。

例えば、アプリ bookstore (manage.py startapp bookstore で作成) がある場合、class Book として定義されたモデルは bookstore_book という名前のデータベーステーブルを持ちます。

データベーステーブル名を上書きするには、 class Meta の db_table パラメータを使用します。

データベースのテーブル名が SQL の予約語だったり、 Python の変数名では許されない文字（特にハイフン）を含んでいたりしても大丈夫です。Django は裏でカラム名とテーブル名をクォート処理します。

MariaDB と MySQL では小文字のテーブル名を使いましょう

特に MySQL バックエンドを使用している場合は、db_table でテーブル名をオーバーライドする際に小文字のテーブル名を使うことを強くお勧めします。詳細は MySQLのノート を参照してください。

オラクルのテーブル名のクォート処理

Oracle のテーブル名の上限である 30 文字の制限を満たし、Oracle データベースの一般的な慣例に合わせるため、 Django はテーブル名を短くしたり、すべて大文字にしたりすることがあります。このような変換を防ぐには、 db_table の値として引用符で囲まれた名前を使います：

db_table = '"name_left_in_lowercase"'

このような引用符で囲まれた名前は、Django がサポートしている他のデータベースバックエンドでも使用できます。詳しくは Oracleのノート を参照してください。

db_table_comment

Options.db_table_comment

このモデルに使うデータベーステーブルのコメントです。あなたの Django コードを見ていない、直接データベースにアクセスできる人のために、 データベーステーブルをドキュメント化するのに便利です。たとえば以下のようにします：

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

db_tablespace

Options.db_tablespace

このモデルに使用する データベーステーブル空間 の名前です。デフォルトはプロジェクトの DEFAULT_TABLESPACE 設定です。バックエンドがテーブル空間をサポートしていない場合、このオプションは無視されます。

default_manager_name

Options.default_manager_name

モデルの _default_manager に使用するマネージャの名前。

default_related_name

Options.default_related_name

リレーション先オブジェクトからこのオブジェクトへのリレーションにデフォルトで使用される名前です。デフォルトは <model_name>_set です。

このオプションは related_query_name も設定します。

フィールドの逆引き名は一意でなければならないので、モデルをサブクラス化する場合は注意してください。名前の衝突を回避するため、名前の一部に '%(app_label)s' と '%(model_name)s' を含めるべきです。これらはそれぞれ、モデルが存在するアプリケーションの名前とモデルの名前に置き換えられます。抽象モデルの related name の段落を参照してください。

get_latest_by

Options.get_latest_by

モデル内のフィールド名またはフィールド名のリスト。通常は DateField, DateTimeField, IntegerField です。これはモデル Manager の latest() と earliest() メソッドで使用するデフォルトのフィールドを指定します。

実装例:

# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]

詳しくは latest() のドキュメントを参照してください。

managed

Options.managed

デフォルトは True です。つまり、 Django は migrate やマイグレーションの一部として適切なデータベーステーブルを作成し、 flush 管理コマンドの一部として削除します。つまり、 Django はデータベーステーブルのライフサイクルを 管理 します。

False の場合、このモデルに対してデータベーステーブルの作成、変更、削除の操作を行いません。これは、モデルが既存のテーブルや他の方法で作成されたデータベースビューを表す場合に便利です。これは managed=False の場合の 唯一の 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。

1. 主キーフィールドを宣言しない場合、モデルに自動的に主キーフィールドを追加します。 後でコードを読む人の混乱を避けるために、管理対象外のモデルを使うときには、モデル化しているデータベーステーブルのすべてのカラムを指定することをお勧めします。

2. managed=False のモデルが ManyToManyField を含み、それが別の管理対象外モデルを指している場合、多対多の結合のための中間テーブルも作成されません。しかし、1つの管理モデルと1つの管理対象外モデル間の中間テーブルは 作成 されます。

   このデフォルトの動作を変更する必要がある場合は、(managed を必要に応じて設定した) 明示的なモデルとして中間テーブルを作成し、 ManyToManyField.through 属性を使用してカスタムモデルとのリレーションを作成します。

managed=False のモデルを含むテストでは、テストのセットアップの一部として正しいテーブルが作成されるようにする必要があります。

モデルクラスの Python レベルでの動作を変更したい場合、 managed=False を使って既存のモデルのコピーを作成することもできます。しかし、その場合はもっと良い方法があります。 プロキシモデル です。

order_with_respect_to

Options.order_with_respect_to

このオブジェクトを指定されたフィールドに対してソート可能にします。通常は ForeignKey です。これは、リレーション先オブジェクトを親オブジェクトに対してソート可能にするために使用できます。例えば、 Answer と Question オブジェクトにリレーションがあり、質問には複数の答えがあり、答えの順番が重要である場合、次のようにします：

from django.db import models


class Question(models.Model):
    text = models.TextField()
    # ...


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = "question"

order_with_respect_to が指定されている場合、リレーション先オブジェクトの順序を取得・設定するための2つのメソッドが追加されます。 get_RELATED_order() と set_RELATED_order() で、 RELATED は小文字のモデル名です。たとえば、ある Question オブジェクトが複数の Answer オブジェクトにリレーションしているとすると、返されるリストにはリレーション先の Answer オブジェクトの主キーが含まれます：

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

Questionオブジェクトのリレーション先の Answer オブジェクトの順番は、 Answer の主キーのリストを渡すことで設定できます：

>>> question.set_answer_order([3, 1, 2])

リレーション先オブジェクトには get_next_in_order() と get_previous_in_order() というメソッドもあり、これらのオブジェクトに適切な順番でアクセスできます。 Answer オブジェクトが id で並べられていると仮定すると、下記のようになります：

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

order_with_respect_to は暗黙で ordering オプションを設定します。

内部的には、 order_with_respect_to は _order という追加のフィールド/データベースカラムを追加し、モデルの ordering オプションをこのフィールドに設定します。そのため、order_with_respect_to と ordering を一緒に使用することはできません。また、order_with_respect_to によって追加された順序は、このモデルのオブジェクトのリストを取得する際に常に適用されます。

order_with_respect_to を変更するとき

order_with_respect_to は新しいデータベースカラムを追加するので、初期マイグレーションの migrate の後に order_with_respect_to を追加または変更する場合は、適切なマイグレーションを作成して適用してください。

ordering

Options.ordering

オブジェクトのリストを取得するときに使用する、オブジェクトのデフォルトの順序：

ordering = ["-order_date"]

これは文字列やクエリ式のタプルまたはリストです。各文字列はフィールド名で、オプションのプレフィックス "-" は降順を表します。先頭の "-" がないフィールドは昇順に並びます。ランダムに並び替えたい場合は、文字列 "?" を使用します。

例えば、 pub_date フィールドで昇順にソートするには、次のようにします：

ordering = ["pub_date"]

pub_date の降順でソートするには、次のようにします：

ordering = ["-pub_date"]

pub_date の降順でソートし、 author の昇順でソートするには、次のようにします：

ordering = ["-pub_date", "author"]

クエリ式 を使うこともできます。 author の昇順で並び替え、null値を最後にソートしたい場合、これを使います:

from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]

警告

ソートには計算コストがかかります。ソート条件に追加した各フィールドに、データベースへのコストが発生します。追加する各外部キーには、暗黙的にすべてのデフォルトのソート条件が含まれます。

クエリでソートが指定されていない場合、データベースから返される結果の順序は指定されません。特定の順序が保証されるのは、結果内の各オブジェクトを一意に識別するフィールドの組み合わせでソートした場合だけです。例えば、 name フィールドが一意でない場合、そのフィールドでソートしても、同じ名前のオブジェクトが常に同じ順序で表示されるとは限りません。

permissions

Options.permissions

このオブジェクトを作成するときに permissions テーブルに入力する追加のパーミッション。追加、変更、削除、表示のパーミッションはそれぞれのモデルに対して自動的に作成されます。この例では can_deliver_pizzas という追加のパーミッションを指定しています：

permissions = [("can_deliver_pizzas", "Can deliver pizzas")]

これは (permission_code, human_readable_permission_name) の形式の2値タプルのリストまたはタプルです。

default_permissions

Options.default_permissions

デフォルトは ('add', 'change', 'delete', 'view') です。このリストはカスタマイズできます。例えば、アプリがデフォルトのパーミッションを必要としない場合は、空のリストを指定します。暗黙的にパーミッションが作成されるのを防ぐには、 migrate によってモデルが作成される前に、モデルに指定する必要があります。

proxy

Options.proxy

proxy = True の場合、他のモデルをサブクラス化したモデルは プロキシモデル として扱われます。

required_db_features

Options.required_db_features

現在の接続が持つべきデータベースの機能のリストで、このリストに基づいてモデルがマイグレーションフェーズで考慮されます。たとえば、このリストを ['gis_enabled'] に設定すると、そのモデルはGISが有効なデータベース上でのみ同期されます。これは、複数のデータベースバックエンドでテストする際に、一部のモデルをスキップするのにも便利です。作成されるかどうかわからないモデル間のリレーションは避けてください。ORMはこれを処理しません。

required_db_vendor

Options.required_db_vendor

このモデルが特定する、サポートされているデータベース・ベンダーの名前。現在の組み込みベンダー名は sqlite, postgresql, mysql, oracle です。この属性が空ではなく、現在の接続ベンダーがこの属性と一致しない場合、モデルは同期されません。

select_on_save

Options.select_on_save

Django が 1.6 より前の django.db.models.Model.save() アルゴリズムを使うかどうかを決定します。古いアルゴリズムでは、 SELECT を使って、更新する既存の行があるかどうかを判断します。新しいアルゴリズムは UPDATE を直接試みます。まれに、既存の行の UPDATE が Django から見えない場合があります。たとえば、PostgreSQL の ON UPDATE トリガーは NULL を返します。このような場合、新しいアルゴリズムは、データベースに行が存在しても、 INSERT を実行してしまいます。

通常、この属性を設定する必要はありません。デフォルトは False です。

新旧の保存アルゴリズムについては django.db.models.Model.save() を参照してください。

indexes

Options.indexes

モデルに定義したい インデックス のリストです：

from django.db import models


class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=["last_name", "first_name"]),
            models.Index(fields=["first_name"], name="first_name_idx"),
        ]

unique_together

Options.unique_together

代わりに UniqueConstraint と constraints オプションを使用してください。

UniqueConstraint は unique_together よりも多くの機能を提供します。 unique_together は将来廃止される可能性があります。

ユニークでなければならないフィールド名のリスト：

unique_together = [["driver", "restaurant"]]

これは、一緒に考えたときに一意でなければならないリストのリストです。Django の管理画面で使われ、データベースレベルで強制されます (つまり、 CREATE TABLE ステートメントに適切な UNIQUE ステートメントが含まれます)。

利便性のために、unique_together は1つのフィールドセットしかないときは1つのリストにできます：

unique_together = ["driver", "restaurant"]

ManyToManyField を unique_together に含めることはできません（それが何を意味するのかさえ不明です！）。ManyToManyField に関連する一意性を検証する必要がある場合は、シグナルを使うか、明示的な through モデルを使用してみてください。

制約に違反したときにモデル検証中に発生する ValidationError は unique_together エラーコードを持ちます。

constraints

Options.constraints

モデルに定義したい 制約 のリスト：

from django.db import models


class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),
        ]

verbose_name

Options.verbose_name

人間が読めるオブジェクトの名前（単数形）：

verbose_name = "pizza"

指定されない場合、 Django はクラス名を小文字にして使います。 CamelCase は camel case になります。

verbose_name_plural

Options.verbose_name_plural

オブジェクトの名前の複数形：

verbose_name_plural = "stories"

指定されない場合、 Django は verbose_name + "s" を使用します。

読み取り専用の Meta 属性

label

Options.label

オブジェクトの表現。app_label.object_name を返します。例： 'polls.Question'

label_lower

Options.label_lower

モデルの表現。app_label.model_name' を返します。例： 'polls.question'