モデルの Meta
オプション¶
このドキュメントでは、モデル内部の class Meta
内でモデルに与えられる、すべての可能な メタデータオプション を説明します。
利用可能な Meta
オプション¶
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
に使用するマネージャの名前。
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
の場合の 唯一の 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。主キーフィールドを宣言しない場合、モデルに自動的に主キーフィールドを追加します。 後でコードを読む人の混乱を避けるために、管理対象外のモデルを使うときには、モデル化しているデータベーステーブルのすべてのカラムを指定することをお勧めします。
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
¶
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
¶ ユニークでなければならないフィールド名のリスト:
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
¶
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"
を使用します。