モデルMetaオプション

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

利用可能なMetaオプション

abstract

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

app_label

Options.app_label

モデルが：setting： `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はモデルクラスとそれを含むアプリの名前からデータベーステーブルの名前を自動的に取得します。モデルのデータベーステーブル名は、モデルの「アプリラベル」（で使用した名前）を結合することによって作成されます：djadmin： `manage.py startapp ` –モデルのクラス名にアンダースコアを付けます。

たとえば、アプリbookstore（manage.py startapp bookstoreによって作成されたもの）がある場合、class Bookとして定義されたモデルには、bookstore_bookという名前のデータベーステーブルがあります。

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

データベースのテーブル名がSQLの予約語である場合、またはPython変数名で許可されていない文字（特にハイフン）が含まれている場合は問題ありません。 Djangoは、舞台裏で列とテーブルの名前を引用しています。

MariaDBとMySQLには小文字のテーブル名を使用します

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

Oracleのテーブル名の引用

Oracleがテーブル名に持つ30文字の制限を満たし、Oracleデータベースの通常の規則に一致させるために、Djangoはテーブル名を短縮してすべて大文字にする場合があります。このような変換を防ぐには、db_tableの値として引用符で囲まれた名前を使用します。

db_table = '"name_left_in_lowercase"'

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

db_tablespace

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

default_manager_name

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

get_latest_by

Options.get_latest_by

モデル内のフィールドの名前またはフィールド名のリスト。通常は DateField 、 DateTimeField 、または IntegerField です。これは、モデルの Manager の latest（）および Early（）メソッドで使用するデフォルトのフィールドを指定します。

例：

# 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が：djadmin： `migrate` に、または移行の一部として適切なデータベーステーブルを作成し、：djadmin：` flushの一部として削除することを意味します。 `管理コマンド。つまり、Djangoはデータベーステーブルのライフサイクルを管理します。

Falseの場合、このモデルに対してデータベーステーブルの作成、変更、または削除操作は実行されません。これは、モデルが他の方法で作成された既存のテーブルまたはデータベースビューを表す場合に役立ちます。これは、managed=Falseの場合ののみの違いです。モデル処理の他のすべての側面は、通常とまったく同じです。これも

宣言しない場合は、モデルに自動主キーフィールドを追加します。後のコードリーダーの混乱を避けるために、アンマネージモデルを使用する場合は、モデル化するデータベーステーブルのすべての列を指定することをお勧めします。
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が設定されている場合、関連オブジェクトの取得と順序の設定を行うために、get_RELATED_order()とset_RELATED_order()の2つの追加メソッドが提供されます。ここで、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()の2つのメソッドもあり、これらを使用してこれらのオブジェクトに適切な順序でアクセスできます。 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は新しいデータベース列を追加するため、最初の：djadmin： `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

このオブジェクトを作成するときにアクセス許可テーブルに入力する追加のアクセス許可。モデルごとに、追加、変更、削除、および表示のアクセス許可が自動的に作成されます。この例では、追加のアクセス許可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')です。たとえば、アプリがデフォルトの権限を必要としない場合は、これを空のリストに設定することで、このリストをカスタマイズできます。省略された権限が作成されないようにするには、：djadmin： `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に表示されない場合があります。例として、NULLを返すPostgreSQL ON UPDATEトリガーがあります。このような場合、データベースに行が存在する場合でも、新しいアルゴリズムは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管理者で使用され、データベースレベルで適用されます（つまり、適切なUNIQUEステートメントがCREATE TABLEステートメントに含まれています）。

便宜上、unique_togetherは、単一のフィールドセットを処理するときに単一のリストにすることができます。

unique_together = ['driver', 'restaurant']

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

制約に違反したときにモデルの検証中に発生したValidationErrorには、unique_togetherエラーコードがあります。

index_together

Options.index_together

代わりに、インデックスオプションを使用してください。

新しい indexes オプションは、index_togetherよりも多くの機能を提供します。 index_togetherは将来廃止される可能性があります。

一緒になってインデックスが付けられるフィールド名のセット：

index_together = [
    ["pub_date", "deadline"],
]

このフィールドのリストは一緒にインデックス付けされます（つまり適切なCREATE INDEXステートメントが発行されます。）

便宜上、index_togetherは、単一のフィールドセットを処理するときに単一のリストにすることができます。

index_together = ["pub_date", "deadline"]

constraints

Options.constraints

モデルで定義する制約のリスト：

from django.db import models

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

    class Meta:
        constraints = [
            models.CheckConstraint(check=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'。

モデルメタオプション—Djangoドキュメント

目次

モデルMetaオプション

利用可能なMetaオプション

abstract

app_label

base_manager_name

db_table

テーブル名

db_tablespace

default_manager_name

get_latest_by

managed

order_with_respect_to

ordering

permissions

default_permissions

proxy

required_db_features

required_db_vendor

select_on_save

indexes

unique_together

index_together

constraints

verbose_name

verbose_name_plural

読み取り専用Meta属性

label

label_lower

モデルメタオプション—Djangoドキュメント

モデルMetaオプション

利用可能なMetaオプション

abstract

app_label

base_manager_name

db_table

テーブル名

db_tablespace

default_manager_name

default_related_name

get_latest_by

managed

order_with_respect_to

ordering

permissions

default_permissions

proxy

required_db_features

required_db_vendor

select_on_save

indexes

unique_together

index_together

constraints

verbose_name

verbose_name_plural

読み取り専用Meta属性

label

label_lower