Meta 选项Link to this heading#本文档解释了所有可能的 元数据选项，你可以在模型的内部 class Meta 中为模型提供这些选项。
Meta 选项Link to this heading#abstractLink to this heading#如果 abstract = True，这个模型将是一个 抽象基类。
app_labelLink to this heading#如果在 INSTALLED_APPS 中定义了一个应用程序之外的模型，它必须声明它属于哪个应用程序：
app_label = "myapp"\n如果你想用 app_label.object_name 或 app_label.model_name 来表示一个模型，你可以分别使用 model._meta.label 或 model._meta.label_lower。
base_manager_nameLink to this heading#管理器的属性名，例如，'objects'，用于模型的 _base_manager。
db_tableLink to this heading#用于模型的数据库表的名称：
\ndb_table = "music_album"\n为了节省你的时间，Django 会自动从你的模型类和包含它的应用程序的名称中导出数据库表的名称。一个模型的数据库表名是通过将模型的“app label”——你在 manage.py startapp 中使用的名称——与模型的类名连接起来，并在两者之间加上下划线。
例如，如果你有一个应用程序 bookstore （由 manage.py startapp bookstore 创建），一个定义为 class Book 的模型将有一个名为 bookstore_book 的数据库表。
要覆盖数据库表名，使用 class Meta 中的 db_table 参数。
如果你的数据库表名是 SQL 的保留字，或者包含 Python 变量名中不允许的字符——特别是连字符——那也没关系。Django 会在幕后引用列名和表名。
\n\n\ndb_table_commentLink to this heading#用于此模型的数据库表的注释。对于具有直接数据库访问权限但可能不查看您的 Django 代码的个人来说，这非常有用，用于文档化数据库表。例如：
\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n answer = models.TextField()\n\n class Meta:\n db_table_comment = "Question answers"\ndb_tablespaceLink to this heading#此模型要使用的 数据库表空间 名称。如果有设置的话，默认是项目的 DEFAULT_TABLESPACE 配置。如果后端不支持表空间，则忽略此选项。
default_manager_nameLink to this heading#模型的 _default_manager 管理器名称。
get_latest_byLink to this heading#模型中的字段名或字段名列表，通常是 DateField，DateTimeField 或 IntegerField。这指定了在你的模型中使用的默认字段 Manager 的 last() 和 earliest() 方法。
举例：
\n# Latest by ascending order_date.\nget_latest_by = "order_date"\n\n# Latest by priority descending, order_date ascending.\nget_latest_by = ["-priority", "order_date"]\n更多内容请参见 last() 文档。
managedLink to this heading#默认为 True，意味着 Django 会在 migrate 中创建相应的数据库表，或者作为迁移的一部分，并作为 flush 管理命令的一部分删除它们。也就是说，Django 管理 数据库表的生命周期。
如果 False，将不对该模型进行数据库表的创建、修改或删除操作。如果该模型代表一个现有的表或一个通过其他方式创建的数据库视图，这一点很有用。这是在 managed=False 时 唯一 的区别。模型处理的所有其他方面都与正常情况完全相同。这包括
Adding an automatic primary key field to the model if you don't\ndeclare it. To avoid confusion for later code readers, it's\nrecommended to specify all the columns from the database table you\nare modeling when using unmanaged models.
如果一个带有 managed=False 的模型包含一个 ManyToManyField 指向另一个非托管模型，那么多对多连接的中间表也不会被创建。但是，一个托管模型和一个非托管模型之间的中间表会被创建。
如果你需要改变这种默认行为，请将中间表创建为显式模型（根据需要设置 managed ），并使用 ManyToManyField.through 属性让关系使用你的自定义模型。
对于涉及 managed=False 模型的测试，你要确保创建正确的表作为测试设置的一部分。
如果你对改变模型类的 Python 级行为感兴趣，你可以使用 managed=False 并创建一个现有模型的副本。然而，对于这种情况，有一个更好的方法： 代理模型。
order_with_respect_toLink to this heading#使该对象可以根据给定字段（通常是 ForeignKey ）进行排序。这可以用来使相关对象相对于父对象可排序。例如，如果一个 Answer 与一个 Question 对象相关，而一个问题有多个答案，并且答案的顺序很重要，你可以这样做：
from django.db import models\n\n\nclass Question(models.Model):\n text = models.TextField()\n # ...\n\n\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n # ...\n\n class Meta:\n order_with_respect_to = "question"\n当设置了 order_with_respect_to 时，会提供两个额外的方法来检索和设置相关对象的顺序：get_RELATED_order() 和 set_RELATED_order()，其中 RELATED 是小写的模型名称。例如，假设一个 Question 对象有多个相关的 Answer 对象，返回的列表包含相关 Answer 对象的主键：
>>> question = Question.objects.get(id=1)\n>>> question.get_answer_order()\n[1, 2, 3]\n可以通过传递一个 Answer 主键列表来设置 Question 对象相关的 Answer 对象的顺序：
>>> question.set_answer_order([3, 1, 2])\n相关的对象还会获得两个方法，get_next_in_order() 和 get_previous_in_order()，可以用来按正确的顺序访问这些对象。假设 Answer 对象按 id 排序：
>>> answer = Answer.objects.get(id=2)\n>>> answer.get_next_in_order()\n<Answer: 3>\n>>> answer.get_previous_in_order()\n<Answer: 1>\norderingLink to this heading#对象的默认排序，用于获取对象列表时：
\nordering = ["-order_date"]\n这是一个字符串和／或查询表达式的元组或列表。每一个字符串都是一个字段名，前面有一个可选的“-”字头，表示降序。没有前缀“-”的字段将按升序排列。使用字符串“?”来随机排序。
\n例如，要按 pub_date 字段升序排列，使用以下方法：
ordering = ["pub_date"]\n要按 pub_date 降序排列，请使用：
ordering = ["-pub_date"]\n要按 pub_date 降序，然后按 author 升序，请使用：
ordering = ["-pub_date", "author"]\n你也可以使用 查询表达式。要按 author 升序排列，并使空值最后排序，请使用：
from django.db.models import F\n\nordering = [F("author").asc(nulls_last=True)]\npermissionsLink to this heading#创建此对象时要输入权限表的额外权限。为每个模型自动创建添加、更改、删除和查看权限。这个例子指定了一个额外的权限，can_deliver_pizzas ：
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]\n这是一个由二元元组组成的列表或元组，格式为 (permission_code, human_readable_permission_name)。
default_permissionsLink to this heading#默认值为 ('add', 'change', 'delete', 'view') 。你可以自定义这个列表，例如，如果你的应用不需要任何默认的权限，可以将其设置为空列表。它必须在模型创建之前通过 migrate 在模型上指定，以防止任何遗漏的权限被创建。
proxyLink to this heading#如果 proxy = True，作为另一个模型子类的模型将被视为 代理模型。
required_db_featuresLink to this heading#当前连接应具备的数据库特征列表，以便在迁移阶段考虑模型。例如，如果你将此列表设置为 ['gis_enabled']，则模型将只在支持 GIS 的数据库上同步。在使用多个数据库后端进行测试时，跳过一些模型也很有用。避免模型之间的关系，这些模型可能会被创建，也可能不会被创建，因为 ORM 不会处理这个问题。
required_db_vendorLink to this heading#本模型所特有的支持的数据库厂商名称。目前的内置厂商名称是： sqlite，postgresql，mysql 和 oracle。如果该属性不为空，且当前连接厂商与之不匹配，则该模型将不会同步。
select_on_saveLink to this heading#Determines if Django will use the pre-1.6\ndjango.db.models.Model.save() algorithm. The old algorithm\nuses SELECT to determine if there is an existing row to be updated.\nThe new algorithm tries an UPDATE directly. In some rare cases the\nUPDATE of an existing row isn't visible to Django. An example is the\nPostgreSQL ON UPDATE trigger which returns NULL. In such cases the\nnew algorithm will end up doing an INSERT even when a row exists in\nthe database.
通常不需要设置这个属性。默认值是 False。
See django.db.models.Model.save() for more about the old and\nnew saving algorithm.
indexesLink to this heading#你想在模型上定义的 indexes 的列表：
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n first_name = models.CharField(max_length=100)\n last_name = models.CharField(max_length=100)\n\n class Meta:\n indexes = [\n models.Index(fields=["last_name", "first_name"]),\n models.Index(fields=["first_name"], name="first_name_idx"),\n ]\nunique_togetherLink to this heading#一组字段名，合起来必须是唯一的：
\nunique_together = [["driver", "restaurant"]]\n这是一个列表，这些列表在一起考虑时必须是唯一的。它 在Django 管理中使用，并在数据库级别执行（即在 CREATE TABLE 语句中包含适当的 UNIQUE 语句）。
为方便起见，unique_together 在处理单组字段时可以是一个单一的列表：
unique_together = ["driver", "restaurant"]\nManyToManyField 不能包含在 unique_together 中。（甚至不清楚这意味着什么！）如果需要验证与 ManyToManyField 相关的唯一性，请尝试使用信号或显式的 through 模型。
在模型验证过程中，当约束条件被违反时引发的 ValidationError 具有 unique_together 错误代码。
constraintsLink to this heading#你想在模型上定义的 约束 列表：
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n age = models.IntegerField()\n\n class Meta:\n constraints = [\n models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),\n ]\nverbose_nameLink to this heading#对象的可读名称，单数：
\nverbose_name = "pizza"\n如果没有给定，Django 将使用一个 munged 版本的类名：CamelCase 变成 camel case。
verbose_name_pluralLink to this heading#对象的复数名称：
\nverbose_name_plural = "stories"\n如果没有给定，Django 将使用 verbose_name + "s"。
Meta 属性Link to this heading#labelLink to this heading#对象的表示，返回 app_label.object_name，例如 'polls.Question'。
label_lowerLink to this heading#模型的表示，返回 app_label.model_name，例如 'polls.question'。