# Django 5.2.9 ドキュメント

# モデルの `Meta` オプション

このドキュメントでは、モデル内部の `class Meta` 内でモデルに与えられる、すべての可能な メタデータオプション を説明します。

## 利用可能な `Meta` オプション

### `abstract`

Options.abstract

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

### `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` に使用するマネージャの名前。

### `default_related_name`

Options.default_related_name

  リレーション先オブジェクトからこのオブジェクトへのリレーションにデフォルトで使用される名前です。デフォルトは `<model_name>_set` です。

  このオプションは `related_query_name` も設定します。

  フィールドの逆引き名は一意でなければならないので、モデルをサブクラス化する場合は注意してください。名前の衝突を回避するため、名前の一部に `'%(app_label)s'` と `'%(model_name)s'` を含めるべきです。これらはそれぞれ、モデルが存在するアプリケーションの名前とモデルの名前に置き換えられます。抽象モデルの related name の段落を参照してください。

### `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` の場合の 唯一の 違いです。モデルの処理に関する他のすべての側面は、通常とまったく同じです。これには以下が含まれます。

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

Default ordering and GROUP BY

In GROUP BY queries (for example, those using `values()` and `annotate()`), the default ordering is not applied.

警告

ソートには計算コストがかかります。ソート条件に追加した各フィールドに、データベースへのコストが発生します。追加する各外部キーには、暗黙的にすべてのデフォルトのソート条件が含まれます。

クエリでソートが指定されていない場合、データベースから返される結果の順序は指定されません。特定の順序が保証されるのは、結果内の各オブジェクトを一意に識別するフィールドの組み合わせでソートした場合だけです。例えば、 `name` フィールドが一意でない場合、そのフィールドでソートしても、同じ名前のオブジェクトが常に同じ順序で表示されるとは限りません。

### `permissions`

Options.permissions

  このオブジェクトを作成するときに 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')` です。このリストはカスタマイズできます。例えば、アプリがデフォルトのパーミッションを必要としない場合は、空のリストを指定します。暗黙的にパーミッションが作成されるのを防ぐには、 `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

  Determines if Django will use the pre-1.6 `django.db.models.Model.save()` algorithm. The old algorithm uses `SELECT` to determine if there is an existing row to be updated. The new algorithm tries an `UPDATE` directly. In some rare cases the `UPDATE` of an existing row isn't visible to Django. An example is the PostgreSQL `ON UPDATE` trigger which returns `NULL`. In such cases the new algorithm will end up doing an `INSERT` even when a row exists in the database.

  通常、この属性を設定する必要はありません。デフォルトは `False` です。

  See `django.db.models.Model.save()` for more about the old and new saving algorithm.

### `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 の管理画面で使われ、データベースレベルで強制されます (つまり、 `CREATE TABLE` ステートメントに適切な `UNIQUE` ステートメントが含まれます)。

  利便性のために、`unique_together` は1つのフィールドセットしかないときは1つのリストにできます：

      unique_together = ["driver", "restaurant"]

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

  制約に違反したときにモデル検証中に発生する `ValidationError` は `unique_together` エラーコードを持ちます。

### `constraints`

Options.constraints

  モデルに定義したい 制約 のリスト：

      from django.db import models

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

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