Meta オプション¶| revision-up-to: | 17812 (1.4) |
|---|
このドキュメントでは、モデルの内部クラス Meta に指定できる
メタデータオプション について解説しています。
Meta オプション¶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 Meta に
db_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 の名前です。
このオプションは、モデルの Manager の latest
メソッドが使うデフォルトのフィールドを指定します。
例えば:
get_latest_by = "order_date"
詳しくは latest() を参照してください。
managed¶Options.managed¶デフォルトでは True です。その場合 Django は適切なデータベーステーブルを
syncdb で作成し、 reset 管理コマンドの処理の中で
削除します。すなわち、 Django がデータベーステーブルのライフサイクルを
“管理する (manage)” ことになります。
False の場合、データベーステーブルの作成や削除がこのモデルのために
行われることはありません。モデルが、他の手段で作成済みのテーブルや
データベースビューを表す場合に、役立つでしょう。これが managed=False
とした場合に起こる 唯一の 違いです。モデルの処理に関して、他はすべて
完全に普通通りです。以下についても同じです:
もし managed=False なモデルが他の “管理しない” モデルを指す
ManyToManyField を含んでいる場合、
many-to-many 結合用の中間テーブルも作成されません。しかし、 “管理する”
モデルと “管理しない” モデルの間の中間テーブルは 作成されます 。
このデフォルトの振る舞いを変更する必要がある場合、中間テーブル用の
明示的なモデルを (必要に応じて managed を指定して) 作成し、
ManyToManyField.through 属性を使ってそのカスタムモデルを
そのリレーションで使うように指定してください。
managed=False としたモデルが関わるテストにおいて、テストのセットアップ
処理で正しいテーブルを作成するかどうかはユーザ次第です。
もしモデルクラスの Python レベルでの振る舞いを変更してみたいのであれば、
managed=False としつつ既存のモデルのコピーを作成することも
可能と言えば可能 です。しかし、その状況であればもっと良いアプローチが
あります: プロキシモデル です。
order_with_respect_to¶Options.order_with_respect_to¶指定したフィールドでオブジェクトを「並べ替え可能 (orderable)」であると宣言します。
このオプションを使うのは、リレーションの張られたオブジェクトを、親オブジェクト
に従って並べ替えたい場合がほとんどです。例えば、 Answer が Question
にリレーションを張っており、一つの 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']
permissions¶Options.permissions¶オブジェクトの生成時にパーミッションテーブルに追加するパーミッションの
リストです。 admin セットをもつオブジェクトには、追加、削除、変更の
パーミッションが自動的に生成されます。以下の例では、 can_deliver_pizzas
という追加のパーミッションを定義しています:
permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
(permission_code, human_readable_permission_name) の形式をとる 2 要素の
タプルからなるリストです。
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 はクラス名を解体した文字列を使います。
例えば CamelCase は camel case になります。
verbose_name_plural¶Options.verbose_name_plural¶オブジェクトの複数形名です:
verbose_name_plural = "stories"
この引数を指定しない場合、Django は verbose_name + "s"
を使います。
Oct 26, 2017