djangodocs

Django 5.1
日本語
Documentation contents

モデルの Meta オプション

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

利用可能な Meta オプション

abstract

Options.abstract

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

app_label

Options.app_label

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

Code
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

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

Code
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 は裏でカラム名とテーブル名をクォート処理します。

db_table_comment

Options.db_table_comment

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

Code
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 に使用するマネージャの名前。

get_latest_by

Options.get_latest_by

モデル内のフィールド名またはフィールド名のリスト。通常は 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() のドキュメントを参照してください。

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 オブジェクトにリレーションがあり、質問には複数の答えがあり、答えの順番が重要である場合、次のようにします：

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>

ordering

Options.ordering

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

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)]

permissions

Options.permissions

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

Code
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

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

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_together

Options.unique_together

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

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 エラーコードを持ちます。

constraints

Options.constraints

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

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_name

Options.verbose_name

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

Code
verbose_name = "pizza"

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

verbose_name_plural

Options.verbose_name_plural

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

Code
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'

This page as Markdown JSON

Edit this page on GitHub Official version