【Django文档转译】第2章：模型层——第1节:模型（模块3：Meta 选项）

【Django文档转译】第2章：模型层——第1节:模型（模块3：Meta 选项）

可得Meta备选方案¶abstract¶

Options.abstract¶ 如果abstract = True，这个模型将是抽象基类.

app_label¶

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¶ 例如，管理器的属性名，‘objects’，用于模型的_base_manager.

db_table¶

Options.db_table¶ 要用于模型的数据库表的名称：

db_table = 'music_album'

表名¶

为了节省时间，Django自动从模型类的名称和包含它的应用程序中派生数据库表的名称。模型的数据库表名是通过加入模型的“app标签”(您在其中使用的名称)来构造的。manage.py startapp-到模型的类名，在它们之间加上下划线。

例如，如果您有一个应用程序bookstore(由manage.py startapp bookstore)，定义为class Book将有一个名为​​bookstore_book.​​

若要重写数据库表名，请使用db_table参数class Meta.

如果您的数据库表名是SQL保留字，或者包含Python变量名(特别是连字符)中不允许的字符，则没关系。Django在幕后引用列和表名。

为MariaDB和MySQL使用小写表名： 强烈建议您在重写表名时使用小写表名。db_table，尤其是当您使用MySQL后端时。见MySQL注释更多细节。

表名引用Oracle 为了满足Oracle对表名的30个字符限制，并与Oracle数据库的通常约定相匹配，Django可以缩短表名并将它们全部大写。若要防止此类转换，请使用引用的名称作为db_table:

db_table = '"name_left_in_lowercase"'

这种引用的名称也可以与Django的其他受支持的数据库后端一起使用；但是，除了Oracle之外，引号没有任何影响。见甲骨文注释更多细节。

db_tablespace¶

Options.db_tablespace¶ 的名称数据库表空间用于这个模型。缺省值是项目的DEFAULT_TABLESPACE设置，如果设置。如果后端不支持表空间，则忽略此选项。

default_manager_name¶

Options.default_manager_name¶

default_related_name¶

Options.default_related_name¶ 默认情况下将用于从相关对象返回到此对象的关系的名称。默认情况是_set.

此选项还设置related_query_name.

由于字段的反向名称应该是唯一的，如果要对模型进行子类，请小心。要解决名称冲突，名称的一部分应该包含’%(app_label)s’和’%(model_name)s’，它们分别替换为模型所在的应用程序的名称和模型的名称，这两个名称都是小写的。见关于抽象模型的相关名称.

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']

managed¶

Options.managed¶ 默认为True，这意味着Django将在migrate或作为迁移的一部分，并将其作为迁移的一部分移除。flush管理指挥部。就是，Django管理数据库表的生命周期。

如果False，将不对此模型执行数据库表创建或删除操作。如果模型表示已通过其他方法创建的现有表或数据库视图，则此操作非常有用。这是只差异时managed=False…模型处理的所有其他方面与正常情况完全相同。这包括

如果一个模型managed=False包含ManyToManyField这指向另一个非托管模型，那么也不会创建多到多连接的中间表。但是，一个托管模型和一个非托管模型之间的中间表将要被创造。

如果需要更改此默认行为，请将中间表创建为显式模型(使用managed)并使用ManyToManyField.through属性使关系使用自定义模型。

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

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

order_with_respect_to¶

Options.order_with_respect_to¶ 使此对象相对于给定​​​字段可排序，​​通常为ForeignKey…这可用于使相对于父对象的相关对象可排序。例如，如果Answer与Question对象，并且一个问题有多个答案，答案的顺序很重要，您可以这样做：

from django.db import modelsclass 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物体：

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

a的顺序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.get_previous_in_order()

在内部，order_with_respect_to添加一个名为_order并设置模型ordering该字段的选项。因此，order_with_respect_to和ordering不能在一起使用，并且order_with_respect_to每当您获得此模型的对象列表时，都会应用。

变幻order_with_respect_to

因为order_with_respect_to添加新的数据库列，如果添加或更改，请确保进行并应用适当的迁移。order_with_respect_to在你的首字母之后migrate.

ordering¶

Options.ordering¶ 对象的默认排序，用于获取对象列表时使用：

ordering = [’-order_date’] 这是字符串和/或查询表达式的元组或列表。每个字符串都是一个带有可选“-”前缀的字段名，它指示降序。没有前导“-”的字段将被命令上升。

例如，通过pub_date字段升序，请使用以下命令：

ordering = [‘pub_date’] 按pub_date下行，使用这个：

ordering = [’-pub_date’] 按pub_date下降，然后author升序，使用这个：

ordering = [’-pub_date’, ‘author’] 您也可以使用查询表达式…按author升序并使空值最后排序，请使用以下命令：

from django.db.models import Fordering = [F('author').asc(nulls_last=True)]

默认排序也会影响聚合查询但这不是从Django 3.1开始的情况。

警告

订购不是免费的操作。添加到订单中的每个字段都会给数据库带来成本。您添加的每个外键也将隐式地包含其所有默认命令。

如果查询没有指定顺序，则将以未指定的顺序从数据库返回结果。只有当一组字段唯一地标识结果中的每个对象时，才能保证特定的排序。例如，如果name字段不是唯一的，按其排序不能保证名称相同的对象总是以相同的顺序出现。

permissions¶

Options.permissions¶ 在创建此对象时输入权限表的额外权限。为每个模型自动创建添加、更改、删除和查看权限。此示例指定额外的权限，can_deliver_pizzas:

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

这是一个格式为2元组的列表或元组。(permission_code, human_readable_permission_name).

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¶ 确定Django是否将使用pre-1.6django.db.models.Model.save()算法。旧算法使用SELECT若要确定是否存在要更新的现有行，请执行以下操作。新算法尝试UPDATE直接。在一些罕见的情况下UPDATE对于Django来说，现有行是不可见的。一个例子是PostgreSQLON UPDATE返回触发器NULL…在这种情况下，新算法最终将执行INSERT即使在数据库中存在一行时也是如此。

通常不需要设置这个属性。默认情况是False.

看见django.db.models.Model.save()有关新旧保存算法的更多信息。

indexes¶

Options.indexes¶ 一份清单指标您想在模型上定义的：

from django.db import modelsclass 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管理中使用，并在数据库级别强制执行(即适当的UNIQUE语句包含在CREATE TABLE发言)。

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

unique_together = [‘driver’, ‘restaurant’] A ManyToManyField不能包含在UNIQUE_CONCE中。(还不清楚这意味着什么！)如果需要验证与ManyToManyField，尝试使用信号或显式through模特。

这个ValidationError在违反约束时在模型验证期间引发的unique_together错误代码。

index_together¶

Options.index_together¶ 使用indexes选择代替。

更新indexes选项提供的功能比index_together. index_together将来可能会被废弃。

这些字段名集合在一起被编入索引：

为了方便起见index_together在处理单个字段集时，可以是一个列表：

index_together = [“pub_date”, “deadline”]

constraints¶

Options.constraints¶ 新设于Django 2.2。 一份清单约束您想在模型上定义的：

from django.db import models

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

class Meta: constraints = [ models.CheckConstraint(check=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，G.‘polls.Question’.

label_lower¶ Options.label_lower¶ 模型的表示，返回app_label.model_name，G.‘polls.question’.

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。