モデルの Meta オプションLink to this heading#

abstractLink to this heading#

Options.abstractLink to this definition#

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

app_labelLink to this heading#

Options.app_labelLink to this definition#

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

Code

app_label = "myapp"

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

base_manager_nameLink to this heading#

Options.base_manager_nameLink to this definition#

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

db_tableLink to this heading#

Options.db_tableLink to this definition#

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

Code

db_table = "music_album"

db_table_commentLink to this heading#

Options.db_table_commentLink to this definition#

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

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

    class Meta:
        db_table_comment = "Question answers"

db_tablespaceLink to this heading#

Options.db_tablespaceLink to this definition#

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

default_manager_nameLink to this heading#

Options.default_manager_nameLink to this definition#

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

default_related_nameLink to this heading#

Options.default_related_nameLink to this definition#

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

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

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

get_latest_byLink to this heading#

Options.get_latest_byLink to this definition#

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

実装例:

Code

# Latest by ascending order_date.
get_latest_by = "order_date"

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

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

managedLink to this heading#

Options.managedLink to this definition#

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

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

1. Adding an automatic primary key field to the model if you don't declare it. To avoid confusion for later code readers, it's recommended to specify all the columns from the database table you are modeling when using unmanaged models.

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

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

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

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

order_with_respect_toLink to this heading#

Options.order_with_respect_toLink to this definition#

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

Code

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 オブジェクトの主キーが含まれます：

Python console

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

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

Python console

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

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

Python console

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

orderingLink to this heading#

Options.orderingLink to this definition#

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

Code

ordering = ["-order_date"]

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

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

Code

ordering = ["pub_date"]

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

Code

ordering = ["-pub_date"]

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

Code

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

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

Code

from django.db.models import F

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

permissionsLink to this heading#

Options.permissionsLink to this definition#

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

Code

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

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

default_permissionsLink to this heading#

Options.default_permissionsLink to this definition#

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

proxyLink to this heading#

Options.proxyLink to this definition#

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

required_db_featuresLink to this heading#

Options.required_db_featuresLink to this definition#

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

required_db_vendorLink to this heading#

Options.required_db_vendorLink to this definition#

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

select_on_saveLink to this heading#

Options.select_on_saveLink to this definition#

Determines if Django will use the pre-1.6 django.db.models.Model.save() algorithm. The old algorithm uses SELECT to determine if there is an existing row to be updated. The new algorithm tries an UPDATE directly. In some rare cases the UPDATE of an existing row isn't visible to Django. An example is the PostgreSQL ON UPDATE trigger which returns NULL. In such cases the new algorithm will end up doing an INSERT even when a row exists in the database.

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

See django.db.models.Model.save() for more about the old and new saving algorithm.

indexesLink to this heading#

Options.indexesLink to this definition#

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

Code

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_togetherLink to this heading#

Options.unique_togetherLink to this definition#

組み合わせが一意でなければならないフィールドのリストを指定します。

Code

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

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

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

Code

unique_together = ["driver", "restaurant"]

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

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

constraintsLink to this heading#

Options.constraintsLink to this definition#

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

Code

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_nameLink to this heading#

Options.verbose_nameLink to this definition#

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

Code

verbose_name = "pizza"

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

verbose_name_pluralLink to this heading#

Options.verbose_name_pluralLink to this definition#

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

Code

verbose_name_plural = "stories"

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

labelLink to this heading#

Options.labelLink to this definition#

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

label_lowerLink to this heading#

Options.label_lowerLink to this definition#

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