モデルの Meta オプション

revision-up-to:11321 (1.1) unfinished

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

Meta オプション

abstract

Options.abstract

True に設定すると、モデルを 抽象ベースクラス にします。

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 はカ ラムとテーブル名を舞台裏でクオート処理するからです。

db_tablespace

Options.db_tablespace
Django 1.0 で新たに登場しました: Please, see the release notes

このフィールドをインデクス化する際に、データベースのテーブルスペース上での フィールドのインデクスの名前に使います。テーブルスペースをサポートしていな いバックエンドでは、このオプションは無視されます。

get_latest_by

Options.get_latest_by

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

例えば:

get_latest_by = "order_date"

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

managed

Options.managed
Django 1.1 で新たに登場しました: Please, see the release notes

Defaults to True, meaning Django will create the appropriate database tables in syncdb and remove them as part of a reset management command. That is, Django manages the database tables' lifecycles.

If False, no database table creation or deletion operations will be performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means. This is the only difference when managed is False. All other aspects of model handling are exactly the same as normal. This includes

  1. Adding an automatic primary key field to the model if you don't declare it. To avoid confusion for later code readers, it's recommended to specify all the columns from the database table you are modeling when using unmanaged models.

  2. If a model with managed=False contains a ManyToManyField that points to another unmanaged model, then the intermediate table for the many-to-many join will also not be created. However, a the intermediary table between one managed and one unmanaged model will be created.

    If you need to change this default behavior, create the intermediary table as an explicit model (with managed set as needed) and use the ManyToManyField.through attribute to make the relation use your custom model.

For tests involving models with managed=False, it's up to you to ensure the correct tables are created as part of the test setup.

If you're interested in changing the Python-level behavior of a model class, you could use managed=False and create a copy of an existing model. However, there's a better approach for that situation: プロキシモデル.

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'

ordering

Options.ordering

オブジェクトのリストを取得するときに使われる、オブジェクトのデフォルトの並 び順規則です:

ordering = ['-order_date']

値は文字列のタプルやリストです。各文字列はフィールドの名前で、降順に並べる 場合にはオプションの "-" を先頭に付けます。先頭に "-" のないフィールドは昇 順に並べられます。順番をランダムにするには "?" を使って下さい。

ノート

ordering にいくつフィールド名を指定しても、 admin は先 頭のフィールドだけを考慮します。

例えば、 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 要素の タプルからなるリストです。

proxy

Options.proxy
Django 1.1 で新たに登場しました: Please, see the release notes

If set to True, a model which subclasses another model will be treated as a proxy model.

unique_together

Options.unique_together

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

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

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

Django 1.0 で新たに登場しました: Please, see the release notes

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

unique_together = ("driver", "restaurant")

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"`` を使います。