モデルの Meta オプション

revision-up-to:17812 (1.4)

このドキュメントでは、モデルの内部クラス Meta に指定できる メタデータオプション について解説しています。

Meta オプション

abstract

Options.abstract

abstract = True に設定すると、このモデルは 抽象ベースクラス になります。

app_label

Options.app_label

もしモデルが標準的な models.py 以外の場所にある場合 (たとえば、 そのアプリのモデルがサブモジュール myapp.models にある場合)、 そのモデルがどのアプリに属しているのか定義する必要があります:

app_label = 'myapp'

db_table

Options.db_table

モデルの使うデータベーステーブルの名前です:

db_table = 'music_album'

テーブル名

ユーザの手間を省くため、 Django はモデルクラスやアプリケーションの名前を 元にデータベーステーブルの名前を導出します。モデルのデータベーステーブル名は、 モデルの「アプリケーションラベル (app label)」、つまり manage.py startapp で指定した名前と、モデルのクラス名をアンダースコアで 結んで生成します。

例えば、 (manage.py startapp bookstore で作成した) bookstore という アプリケーションの中に class Book で定義したモデルがあった場合その データベーステーブルの名前は bookstore_book です。

データベーステーブル名をオーバライドしたければ、 class Metadb_table パラメタを設定します。

データベーステーブル名が SQL の予約語と一致している場合や、ハイフンのように Python の変数名として扱えない文字を含んでいても問題ありません。 Django は カラムとテーブル名を舞台裏でクオート処理するからです。

MySQL のために小文字のテーブル名を使うこと

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

db_tablespace

Options.db_tablespace

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

get_latest_by

Options.get_latest_by

モデル中の DateField または DateTimeField の名前です。 このオプションは、モデルの Managerlatest メソッドが使うデフォルトのフィールドを指定します。

例えば:

get_latest_by = "order_date"

詳しくは latest() を参照してください。

managed

Options.managed

デフォルトでは True です。その場合 Django は適切なデータベーステーブルを syncdb で作成し、 reset 管理コマンドの処理の中で 削除します。すなわち、 Django がデータベーステーブルのライフサイクルを “管理する (manage)” ことになります。

False の場合、データベーステーブルの作成や削除がこのモデルのために 行われることはありません。モデルが、他の手段で作成済みのテーブルや データベースビューを表す場合に、役立つでしょう。これが managed=False とした場合に起こる 唯一の 違いです。モデルの処理に関して、他はすべて 完全に普通通りです。以下についても同じです:

  1. (訳注: どのフィールドが主キーであるかを) 宣言しない限り、自動的に 主キーフィールドをモデルに追加します。”管理しない” モデルを使っている 場合、後でコードを読む人が混乱しないように、モデリングしている データベーステーブルの全カラムを指定することをお勧めします。
  1. もし managed=False なモデルが他の “管理しない” モデルを指す ManyToManyField を含んでいる場合、 many-to-many 結合用の中間テーブルも作成されません。しかし、 “管理する” モデルと “管理しない” モデルの間の中間テーブルは 作成されます

    このデフォルトの振る舞いを変更する必要がある場合、中間テーブル用の 明示的なモデルを (必要に応じて managed を指定して) 作成し、 ManyToManyField.through 属性を使ってそのカスタムモデルを そのリレーションで使うように指定してください。

managed=False としたモデルが関わるテストにおいて、テストのセットアップ 処理で正しいテーブルを作成するかどうかはユーザ次第です。

もしモデルクラスの Python レベルでの振る舞いを変更してみたいのであれば、 managed=False としつつ既存のモデルのコピーを作成することも 可能と言えば可能 です。しかし、その状況であればもっと良いアプローチが あります: プロキシモデル です。

order_with_respect_to

Options.order_with_respect_to

指定したフィールドでオブジェクトを「並べ替え可能 (orderable)」であると宣言します。 このオプションを使うのは、リレーションの張られたオブジェクトを、親オブジェクト に従って並べ替えたい場合がほとんどです。例えば、 AnswerQuestion にリレーションを張っており、一つの Question に複数の Answer があっ て、 Answer の順番が重要である場合は以下のようにします:

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

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

関係づけられたオブジェクトには、さらに 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 を変更する

order_with_respect_to_order という名前で追加のフィールド / データベースカラムを追加します。そのため最初の syncdb の後に 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']
Django 1.4 で変更されました: Django の admin はリスト・タプル中の全要素をちゃんと扱います。 1.4 以前は、最初の要素以外は無視されました。

permissions

Options.permissions

オブジェクトの生成時にパーミッションテーブルに追加するパーミッションの リストです。 admin セットをもつオブジェクトには、追加、削除、変更の パーミッションが自動的に生成されます。以下の例では、 can_deliver_pizzas という追加のパーミッションを定義しています:

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

(permission_code, human_readable_permission_name) の形式をとる 2 要素の タプルからなるリストです。

proxy

Options.proxy

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

unique_together

Options.unique_together

組み合わせとして一意にしなければならないフィールドセットのリストです:

unique_together = (("driver", "restaurant"),)

このリストは、フィールド名のリストからなるリストです。各要素のリストに 入っているフィールドの値の組み合わせは、データベース上で一意でなければ なりません。この制約は Django の admin 上で使われるとともに、データベース レベルでも強制されます (すなわち、適切な UNIQUE 文が CREATE TABLE 文に入ります)。

便宜上、 unique_together は一つのリストのときは単一セットのフィールド として扱います:

unique_together = ("driver", "restaurant")

unique_together に ManyToManyField を含めることはできません。(何を意味しているのかハッキリしません!) ManyToManyField に関係した一意性を検証する 必要があるのであれば、シグナルか、明示的な through モデルを使ってみてください。

verbose_name

Options.verbose_name

人間可読なオブジェクト名の単数形です:

verbose_name = "pizza"

この引数を指定しない場合、Django はクラス名を解体した文字列を使います。 例えば CamelCasecamel case になります。

verbose_name_plural

Options.verbose_name_plural

オブジェクトの複数形名です:

verbose_name_plural = "stories"

この引数を指定しない場合、Django は verbose_name + "s" を使います。