Verbose name plural django что это

18.12.202304.09.2023 admin 0 Comments

Documentation

Model Meta options¶

Available Meta options¶

abstract ¶

app_label ¶

If you want to represent a model with the format app_label.object_name or app_label.model_name you can use model._meta.label or model._meta.label_lower respectively.

base_manager_name ¶

db_table ¶

The name of the database table to use for the model:

Table names¶

To save you time, Django automatically derives the name of the database table from the name of your model class and the app that contains it. A model’s database table name is constructed by joining the model’s “app label” – the name you used in manage.py startapp – to the model’s class name, with an underscore between them.

If your database table name is an SQL reserved word, or contains characters that aren’t allowed in Python variable names – notably, the hyphen – that’s OK. Django quotes column and table names behind the scenes.

Use lowercase table names for MariaDB and MySQL

Table name quoting for Oracle

In order to meet the 30-char limitation Oracle has on table names, and match the usual conventions for Oracle databases, Django may shorten table names and turn them all-uppercase. To prevent such transformations, use a quoted name as the value for db_table :

Such quoted names can also be used with Django’s other supported database backends; except for Oracle, however, the quotes have no effect. See the Oracle notes for more details.

db_tablespace ¶

The name of the database tablespace to use for this model. The default is the project’s DEFAULT_TABLESPACE setting, if set. If the backend doesn’t support tablespaces, this option is ignored.

default_manager_name ¶

default_related_name ¶

get_latest_by ¶

See the latest() docs for more.

managed ¶

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.

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, 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.

order_with_respect_to ¶

The order of a Question object’s related Answer objects can be set by passing in a list of Answer primary keys:

order_with_respect_to implicitly sets the ordering option

Internally, order_with_respect_to adds an additional field/database column named _order and sets the model’s ordering option to this field. Consequently, order_with_respect_to and ordering cannot be used together, and the ordering added by order_with_respect_to will apply whenever you obtain a list of objects of this model.

ordering ¶

The default ordering for the object, for use when obtaining lists of objects:

This is a tuple or list of strings and/or query expressions. Each string is a field name with an optional “-” prefix, which indicates descending order. Fields without a leading “-” will be ordered ascending. Use the string “?” to order randomly.

For example, to order by a pub_date field ascending, use this:

To order by pub_date descending, use this:

To order by pub_date descending, then by author ascending, use this:

Ordering is not a free operation. Each field you add to the ordering incurs a cost to your database. Each foreign key you add will implicitly include all of its default orderings as well.

If a query doesn’t have an ordering specified, results are returned from the database in an unspecified order. A particular ordering is guaranteed only when ordering by a set of fields that uniquely identify each object in the results. For example, if a name field isn’t unique, ordering by it won’t guarantee objects with the same name always appear in the same order.

permissions ¶

Extra permissions to enter into the permissions table when creating this object. Add, change, delete, and view permissions are automatically created for each model. This example specifies an extra permission, can_deliver_pizzas :

default_permissions ¶

proxy ¶

required_db_features ¶

required_db_vendor ¶

select_on_save ¶

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

indexes ¶

A list of indexes that you want to define on the model:

Источник

Документация Django 1.4

Параметры Meta ¶

abstract ¶

app_label ¶

Если модель находится не в models.py (например, модели находятся в модулях пакета myapp.models ), модель должна определять к какому приложению принадлежит модель:

db_table ¶

Название таблицы в базе данных для этой модели:

Название таблицы¶

Если имя колонки это зарезервированное SQL слово, или содержит символы запрещенные в названиях переменной в Python – в частности, дефис – все нормально. Django автоматически экранирует название колонок и таблиц.

Use lowercase table names for MySQL

db_tablespace ¶

get_latest_by ¶

managed ¶

Правильное создание таблиц при тестировании в тестовой базе данных для модели с managed=False ложится на ваши плечи.

Если вы хотите переопределить поведение модели на уровне Python, вы можете использовать managed=False и создать копию существующей модели. Однако, есть лучшее решение для такой ситуации: Proxy-модели.

order_with_respect_to ¶

Для определения порядка объектов Answer передайте список первичных ключей в метод set_answer_order :

ordering ¶

Сортировка по-умолчанию используемая при получении объектов:

Это кортеж или список строк. Каждая строка это название поля с необязательным префиксом “-”, который указывает на нисходящую сортировку. Поля без “-” будут отсортированы по возрастанию. Используйте ”?” для случайной сортировке.

Например, для сортировки по возрастанию по полю pub_date :

Нисходящая сортировка по полю pub_date :

permissions ¶

Дополнительные разрешения(permissions) будут добавлены в таблицу разрешений при создании модели. Разрешения на добавление, удаление и изменение автоматически создаются для каждой модели. Этот пример добавляет разрешение can_deliver_pizzas :

proxy ¶

unique_together ¶

Множество полей, комбинация значений которых должна быть уникальна:

Используется в интерфейсе администратора для проверки данных и на уровне базы данных (то есть соответствующее определение UNIQUE будет добавлено в CREATE TABLE запрос).

Для удобства unique_together может быть одноуровневым списком, если определяется один набор уникальных полей:

verbose_name ¶

Читабельное название модели, в единственном числе:

verbose_name_plural ¶

Название модели в множественном числе:

Источник

Meta Варианты модели ¶

Доступные Meta варианты ¶

abstract ¶

app_label ¶

Если вы хотите представить модель в формате app_label.object_name или, app_label.model_name вы можете использовать model._meta.label или model._meta.label_lower соответственно.

base_manager_name ¶

db_table ¶

Имя таблицы базы данных для использования в модели:

Имена таблиц ¶

Используйте строчные имена таблиц для MariaDB и MySQL

Цитирование имен таблиц для Oracle

Чтобы соответствовать ограничению Oracle на 30 символов для имен таблиц и соответствовать обычным соглашениям для баз данных Oracle, Django может сокращать имена таблиц и переводить их в верхний регистр. Чтобы предотвратить такие преобразования, используйте имя в кавычках в качестве значения для db_table :

Такие имена в кавычках также можно использовать с другими поддерживаемыми базами данных Django; Однако, за исключением Oracle, кавычки не действуют. См. Примечания Oracle для получения более подробной информации.

db_tablespace ¶

default_manager_name ¶

default_related_name ¶

get_latest_by ¶

См. latest() Документацию для получения дополнительной информации.

managed ¶

По умолчанию это True означает, что Django создаст соответствующие таблицы базы данных в процессе migrate миграции или как ее часть и удалит их как часть команды flush управления. То есть Django управляет жизненными циклами таблиц базы данных.

Добавление в модель автоматического поля первичного ключа, если вы его не объявляете. Чтобы избежать путаницы для более поздних программ чтения кода, рекомендуется указать все столбцы из таблицы базы данных, которую вы моделируете, при использовании неуправляемых моделей.

Если модель с managed=False содержит, ManyToManyField который указывает на другую неуправляемую модель, то промежуточная таблица для соединения «многие ко многим» также не будет создана. Однако промежуточная таблица между одной управляемой и одной неуправляемой моделью будет создана.

Если вам нужно изменить это поведение по умолчанию, создайте промежуточную таблицу как явную модель (с managed установленной по мере необходимости) и используйте ManyToManyField.through атрибут, чтобы отношение использовало вашу пользовательскую модель.

order_with_respect_to ¶

Порядок Question объектов, связанных с Answer объектом, можно установить, передав список Answer первичных ключей:

order_with_respect_to неявно устанавливает ordering параметр

Внутренне order_with_respect_to добавляет дополнительное поле / столбец базы данных с именем _order и устанавливает параметр модели ordering для этого поля. Следовательно, order_with_respect_to и ordering не могут использоваться вместе, и порядок, добавленный с помощью, order_with_respect_to будет применяться всякий раз, когда вы получаете список объектов этой модели.

ordering ¶

Порядок по умолчанию для объекта, используемый при получении списков объектов:

Это кортеж или список строк и / или выражений запроса. Каждая строка представляет собой имя поля с необязательным префиксом «-», указывающим на убывающий порядок. Поля без знака «-» будут отсортированы по возрастанию. Используйте строку «?» на заказ случайным образом.

Например, чтобы отсортировать по pub_date полю по возрастанию, используйте это:

Чтобы упорядочить по pub_date убыванию, используйте это:

Чтобы упорядочить по pub_date убыванию, а затем по author возрастанию, используйте это:

Заказ не является бесплатной операцией. Каждое поле, которое вы добавляете в заказ, требует затрат для вашей базы данных. Каждый добавляемый вами внешний ключ будет неявно включать все свои порядки по умолчанию.

Если для запроса не указан порядок, результаты возвращаются из базы данных в неопределенном порядке. Определенный порядок гарантируется только при упорядочивании по набору полей, которые однозначно идентифицируют каждый объект в результатах. Например, если name поле не является уникальным, его упорядочение не гарантирует, что объекты с одинаковым именем всегда будут отображаться в одном и том же порядке.

permissions ¶

Дополнительные разрешения для ввода в таблицу разрешений при создании этого объекта. Разрешения на добавление, изменение, удаление и просмотр автоматически создаются для каждой модели. В этом примере указывается дополнительное разрешение can_deliver_pizzas :

default_permissions ¶

proxy ¶

required_db_features ¶

required_db_vendor ¶

select_on_save ¶

См. django.db.models.Model.save() Дополнительные сведения о старом и новом алгоритме сохранения.

indexes ¶

Список индексов, которые вы хотите определить в модели:

unique_together ¶

Вместо этого используйте UniqueConstraint с constraints опцией.

Наборы имен полей, вместе взятые, должны быть уникальными:

Это список списков, которые должны быть уникальными при рассмотрении вместе. Он используется в администраторе Django и применяется на уровне базы данных (т. Е. Соответствующие UNIQUE операторы включены в оператор). CREATE TABLE

Для удобства unique_together при работе с одним набором полей может быть единый список:

index_together ¶

indexes Вместо этого используйте эту опцию.

Наборы имен полей, которые, вместе взятые, индексируются:

Этот список полей будет проиндексирован вместе (т. Е. Будет выдано соответствующее заявление.) CREATE INDEX

Для удобства index_together при работе с одним набором полей может быть единый список:

constraints ¶

Список ограничений, которые вы хотите определить для модели:

verbose_name ¶

Удобочитаемое имя объекта в единственном числе:

verbose_name_plural ¶

Имя объекта во множественном числе:

Источник

Мета-класс в моделях Django

класс Мета в Django

Класс Meta может использоваться для определения различных вещей о модели, таких как разрешения, имя базы данных, единственное и множественное число, абстракция, порядок и т. Д. Добавление классов Meta в модели Django совершенно необязательно.

Этот класс также имеет множество параметров, которые вы можете настроить. Ниже приведены некоторые из наиболее часто используемых мета-параметров; вы можете изучить все мета-варианты здесь

Модели, заданные как абстрактные, могут быть только наследованы. Эту опцию можно использовать, если есть несколько моделей с общими полями.

Эта опция используется для установки имени, которое должно использоваться для идентификации таблицы в базе данных. Например: если я сделаю что-то следующее, имя моей модели будет job в базе данных.

Эта опция принимает список строковых значений, которые являются полями модели. Он используется для определения порядка объектов модели. Когда объекты этой модели будут извлечены, они будут представлены в этом порядке.

Эта опция используется для определения удобочитаемого единственного имени модели и заменяет стандартное соглашение об именах Django. Это имя также отобразится в панели администратора ( /admin/ ).

Этот параметр используется для определения удобочитаемого имени во множественном числе для модели, которое снова перезапишет стандартное соглашение об именах Django. Это имя также отобразится в панели администратора ( /admin/ ).

Источник

документация Django 3.0

Параметры Meta ¶

abstract ¶

app_label ¶

base_manager_name ¶

db_table ¶

Название таблицы в базе данных для этой модели:

Название таблицы¶

Экономя ваше время, Django автоматически создаст название таблицы из названия модели и приложения. Название таблицы состоит из названия приложения(«app label») – название используемое для команды manage.py startapp – и названия модели, объединенные нижним подчеркиванием.

Use lowercase table names for MariaDB and MySQL

Названия таблиц в кавычках для Oracle

Т.к в Oracle есть ограничение в 30 символов на название таблиц, и для соблюдения соглашений работы с Oracle, Django может ограничить название таблицы и преобразовать его в верхний регистр. Чтобы избежать этого, укажите название в кавычках в настройке db_table :

db_tablespace ¶

default_manager_name ¶

default_related_name ¶

get_latest_by ¶

managed ¶

Если модель с managed=False содержит ManyToManyField на другую неуправляемую модель, промежуточная таблица для хранения связи многое-ко-многим не будет создана. Однако, промежуточная таблица между управляемой и не управляемой моделью будет создана.

order_with_respect_to ¶

Для определения порядка объектов Answer передайте список первичных ключей в метод set_answer_order :

order_with_respect_to неявно использует ordering

ordering ¶

Сортировка по умолчанию используемая при получении объектов:

This is a tuple or list of strings and/or query expressions. Each string is a field name with an optional «-» prefix, which indicates descending order. Fields without a leading «-» will be ordered ascending. Use the string «?» to order randomly.

Например, для сортировки по возрастанию по полю pub_date :

Нисходящая сортировка по полю pub_date :

Default ordering also affects aggregation queries but this won’t be the case starting in Django 3.1.

Сортировка не бесплатная операция. Каждое поле влияет на скорость выполнения запроса. Каждый внешний ключ добавит сортировку по умолчанию связанной модели.