模型 Meta 选项Link to this heading#

abstractLink to this heading#

Options.abstractLink to this definition#

如果 abstract = True，这个模型将是一个 抽象基类。

app_labelLink to this heading#

Options.app_labelLink to this definition#

如果在 INSTALLED_APPS 中定义了一个应用程序之外的模型，它必须声明它属于哪个应用程序：

Code

app_label = "myapp"

如果你想用 app_label.object_name 或 app_label.model_name 来表示一个模型，你可以分别使用 model._meta.label 或 model._meta.label_lower。

base_manager_nameLink to this heading#

Options.base_manager_nameLink to this definition#

管理器的属性名，例如，'objects'，用于模型的 _base_manager。

db_tableLink to this heading#

Options.db_tableLink to this definition#

用于模型的数据库表的名称：

Code

db_table = "music_album"

db_table_commentLink to this heading#

Options.db_table_commentLink to this definition#

用于此模型的数据库表的注释。对于具有直接数据库访问权限但可能不查看您的 Django 代码的个人来说，这非常有用，用于文档化数据库表。例如：

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

db_tablespaceLink to this heading#

Options.db_tablespaceLink to this definition#

此模型要使用的 数据库表空间 名称。如果有设置的话，默认是项目的 DEFAULT_TABLESPACE 配置。如果后端不支持表空间，则忽略此选项。

default_manager_nameLink to this heading#

Options.default_manager_nameLink to this definition#

模型的 _default_manager 管理器名称。

default_related_nameLink to this heading#

Options.default_related_nameLink to this definition#

从相关对象到这个对象的关系默认使用的名称。默认为 <model_name>_set。

这个选项还可以设置 related_query_name。

由于字段的反向名称应该是唯一的，所以如果你打算对你的模型进行子类化，就要小心了。为了避免名称冲突，名称的一部分应该包含 '%(app_label)s' 和 '%(model_name)s'，它们分别被模型所在的应用程序的名称和模型的名称所取代，都是小写的。见 抽象模型的相关名称 段落。

get_latest_byLink to this heading#

Options.get_latest_byLink to this definition#

模型中的字段名或字段名列表，通常是 DateField，DateTimeField 或 IntegerField。这指定了在你的模型中使用的默认字段 Manager 的 last() 和 earliest() 方法。

举例：

Code

# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]

更多内容请参见 last() 文档。

managedLink to this heading#

Options.managedLink to this definition#

默认为 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 指向另一个非托管模型，那么多对多连接的中间表也不会被创建。但是，一个托管模型和一个非托管模型之间的中间表会被创建。

   如果你需要改变这种默认行为，请将中间表创建为显式模型（根据需要设置 managed ），并使用 ManyToManyField.through 属性让关系使用你的自定义模型。

对于涉及 managed=False 模型的测试，你要确保创建正确的表作为测试设置的一部分。

如果你对改变模型类的 Python 级行为感兴趣，你可以使用 managed=False 并创建一个现有模型的副本。然而，对于这种情况，有一个更好的方法： 代理模型。

order_with_respect_toLink to this heading#

Options.order_with_respect_toLink to this definition#

使该对象可以根据给定字段（通常是 ForeignKey ）进行排序。这可以用来使相关对象相对于父对象可排序。例如，如果一个 Answer 与一个 Question 对象相关，而一个问题有多个答案，并且答案的顺序很重要，你可以这样做：

Code

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 时，会提供两个额外的方法来检索和设置相关对象的顺序：get_RELATED_order() 和 set_RELATED_order()，其中 RELATED 是小写的模型名称。例如，假设一个 Question 对象有多个相关的 Answer 对象，返回的列表包含相关 Answer 对象的主键：

Python console

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

可以通过传递一个 Answer 主键列表来设置 Question 对象相关的 Answer 对象的顺序：

Python console

>>> question.set_answer_order([3, 1, 2])

相关的对象还会获得两个方法，get_next_in_order() 和 get_previous_in_order()，可以用来按正确的顺序访问这些对象。假设 Answer 对象按 id 排序：

Python console

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

orderingLink to this heading#

Options.orderingLink to this definition#

对象的默认排序，用于获取对象列表时：

Code

ordering = ["-order_date"]

这是一个字符串和／或查询表达式的元组或列表。每一个字符串都是一个字段名，前面有一个可选的“-”字头，表示降序。没有前缀“-”的字段将按升序排列。使用字符串“?”来随机排序。

例如，要按 pub_date 字段升序排列，使用以下方法：

Code

ordering = ["pub_date"]

要按 pub_date 降序排列，请使用：

Code

ordering = ["-pub_date"]

要按 pub_date 降序，然后按 author 升序，请使用：

Code

ordering = ["-pub_date", "author"]

你也可以使用 查询表达式。要按 author 升序排列，并使空值最后排序，请使用：

Code

from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]

permissionsLink to this heading#

Options.permissionsLink to this definition#

创建此对象时要输入权限表的额外权限。为每个模型自动创建添加、更改、删除和查看权限。这个例子指定了一个额外的权限，can_deliver_pizzas ：

Code

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

这是一个由二元元组组成的列表或元组，格式为 (permission_code, human_readable_permission_name)。

default_permissionsLink to this heading#

Options.default_permissionsLink to this definition#

默认值为 ('add', 'change', 'delete', 'view') 。你可以自定义这个列表，例如，如果你的应用不需要任何默认的权限，可以将其设置为空列表。它必须在模型创建之前通过 migrate 在模型上指定，以防止任何遗漏的权限被创建。

proxyLink to this heading#

Options.proxyLink to this definition#

如果 proxy = True，作为另一个模型子类的模型将被视为 代理模型。

required_db_featuresLink to this heading#

Options.required_db_featuresLink to this definition#

当前连接应具备的数据库特征列表，以便在迁移阶段考虑模型。例如，如果你将此列表设置为 ['gis_enabled']，则模型将只在支持 GIS 的数据库上同步。在使用多个数据库后端进行测试时，跳过一些模型也很有用。避免模型之间的关系，这些模型可能会被创建，也可能不会被创建，因为 ORM 不会处理这个问题。

required_db_vendorLink to this heading#

Options.required_db_vendorLink to this definition#

本模型所特有的支持的数据库厂商名称。目前的内置厂商名称是： sqlite，postgresql，mysql 和 oracle。如果该属性不为空，且当前连接厂商与之不匹配，则该模型将不会同步。

select_on_saveLink to this heading#

Options.select_on_saveLink to this definition#

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.

indexesLink to this heading#

Options.indexesLink to this definition#

你想在模型上定义的 indexes 的列表：

Code

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_togetherLink to this heading#

Options.unique_togetherLink to this definition#

一组字段名，合起来必须是唯一的：

Code

unique_together = [["driver", "restaurant"]]

这是一个列表，这些列表在一起考虑时必须是唯一的。它 在Django 管理中使用，并在数据库级别执行（即在 CREATE TABLE 语句中包含适当的 UNIQUE 语句）。

为方便起见，unique_together 在处理单组字段时可以是一个单一的列表：

Code

unique_together = ["driver", "restaurant"]

ManyToManyField 不能包含在 unique_together 中。（甚至不清楚这意味着什么！）如果需要验证与 ManyToManyField 相关的唯一性，请尝试使用信号或显式的 through 模型。

在模型验证过程中，当约束条件被违反时引发的 ValidationError 具有 unique_together 错误代码。

constraintsLink to this heading#

Options.constraintsLink to this definition#

你想在模型上定义的 约束 列表：

Code

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_nameLink to this heading#

Options.verbose_nameLink to this definition#

对象的可读名称，单数：

Code

verbose_name = "pizza"

如果没有给定，Django 将使用一个 munged 版本的类名：CamelCase 变成 camel case。

verbose_name_pluralLink to this heading#

Options.verbose_name_pluralLink to this definition#

对象的复数名称：

Code

verbose_name_plural = "stories"

如果没有给定，Django 将使用 verbose_name + "s"。

labelLink to this heading#

Options.labelLink to this definition#

对象的表示，返回 app_label.object_name，例如 'polls.Question'。

label_lowerLink to this heading#

Options.label_lowerLink to this definition#

模型的表示，返回 app_label.model_name，例如 'polls.question'。