Verbose name django что это

The use of model field "verbose name"

If I have a web app that use only one language and it is not English, is that correct to use model field verbose_name attribute for the field description (that will be printed in form)? I dont use the translation modules.

1 Answer 1

Verbose Field Names are optional. They are used if you want to make your model attribute more readable, there is no need to define verbose name if your field attribute is easily understandable. If not defined, django automatically creates it using field’s attribute name. Ex : student_name = models.CharField(max_length=30) In this example, it is understood that we are going to store Student’s name, so no need to define verbose explicitly.

Ex : name = models.CharField(max_length=30)

In this example, one may be confused what to store — name of student or Teacher. So, we can define a verbose name.

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

Django — это высокоуровневый веб-фреймворк Python, который способствует быстрой разработке и чистому, прагматичному дизайну. Созданный опытными программистами, он берет на себя большую часть хлопот, связанных с веб-разработкой, так что вы можете сосредоточиться на написании своего приложения без необходимости изобретать колесо. Он бесплатный и с открытым исходным кодом. Перед тем, как двигаться дальше, изучите модели Django.

Метамодель (Meta Model) — это, по сути, внутренний класс вашего класса модели. Метамодель в основном используется для изменения поведения полей вашей модели, таких как изменение опций заказа, verbose_name, и многих других параметров. Добавление класса Meta к вашей модели совершенно необязательно. Для того чтобы использовать метамодель, вы должны добавить класс Meta в вашу модель, как показано ниже:

Опции метамодели

Метамодель имеет множество опций, которые вы можете предоставить вашей модели в ее внутреннем классе meta

1. abstract

Если abstract = True, то данная модель будет абстрактным базовым классом:

2. app_label

Если модель определена за пределами приложений в INSTALLED_APPS , то ей необходимо объявить, какому приложению она принадлежит:

3. verbose_name

verbose_name — это по сути понятное человеку имя для вашей модели.

4. ordering

Ordering (упорядочивание) в основном используется для изменения порядка полей вашей модели.

Добавьте упорядочивание вот так [-1], и порядок изменится на убывающий.

5. proxy

Если мы добавим proxy = True, модель, которая является подклассом другой модели, будет рассматриваться как прокси-модель.

Вот как мы можем создать прокси-модель.

6. permissions

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

Вы можете добавить дополнительные разрешения внутри списка.

7. db_table

Мы можем перезаписать имя таблицы, используя db_table в классе meta.

Это изменит имя таблицы на X.

8. get_latest_by

Возвращает последний объект в таблице на основе заданного поля, обычно используемого для DateField, DateTimeField или IntegerField.

Возвращает последний по порядку возрастания order_date .

Методы класса (classmethod): нужны ли они? Об этом расскажем на бесплатном вебинаре, который пройдет уже 12 октября. Поговорим об особенностях ООП в python: о наследовании и миксинах, рассмотрим ситуации, когда без classmethod не обойтись, посмотрим на реализации в известных библиотеках.

Name already in use

django-training / docs / django-models-in-depth.rst

• Go to file T
• Go to line L
• Copy path
• Copy permalink

• Open with Desktop
• View raw
• Copy raw contents Copy raw contents

Copy raw contents

Copy raw contents

Models In Depth

In our quickstart run through in the previous section we created a simple model and saw how you can manipulate the model using the django python console. We also saw that you can create a user interface for the model quickly by using the admin application that comes as a standard part of django.

The heart of Django is the :abbr:`ORM (Object Relational Mapping)` functionality it provides. With Django, you program and think in python and the application framework does all the nuts and bolts stuff behind the scenes or serialising your saved models into the database and deserialising the models again when you need to access them.

We saw a simple example of this, for example by doing:

A record was created in the database representing the model. And when we did:

The django framework took care of deserialising the model from the database and making it available to us as a python object. Models are by convention defined in :file:`<yourapp>/models.py` . Defining a model is simply a matter of adding a new class to the above file.

The model creation consists of four steps:

• Create a new class that inherits from //models.Model// in :file:`<yourapp>/models.py` . This class will be mapped to a table entity on the database backend.
• Add the property definitions to your class. These will be mapped to fields in the table on the database backend.
• Define the metadata inner class. This provides you a way to specify how the models should be shown to the users and created in the database. For example, you can use the metadata inner class to specify a non-default backend table name.
• Use the manage.py syncdb command to create the backend database model and perform an integrity check of the model.

Lets look again at the model definition we created earlier, but with some extra comments:

The different types of field that you can use in django models are described in the Django documentation. There are a number of different field types you can use, including special types that will build foriegn key constraints, multikey join tables, lookup lists and so on. Here is a complete list of allowed types:

Standard field types:

• AutoField
• BooleanField
• CharField
• CommaSeparatedIntegerField
• DateField
• DateTimeField
• DecimalField
• EmailField
• FileField
• FilePathField
• FloatField
• ImageField
• IntegerField
• IPAddressField
• NullBooleanField
• PositiveIntegerField
• PositiveSmallIntegerField
• SlugField
• SmallIntegerField
• TextField
• TimeField
• URLField
• XMLField

• ForeignKey
• ManyToManyField
• OneToOneField

Spatial field types:

• PointField
• LineStringField
• PolygonField
• MultiPointField
• MultiLineStringField
• MultiPolygonField
• GeometryCollectionField

For foreign key and other relationship fields, you must place the verbose name after the relation name. e.g:

If you want to restrict the values that a user can choose from in order to populate the field. You can do this using a list e.g.:

Then when you create your field you would do:

If you open the doodle model in the admin web interface, you should see that the text field for name is now replaced with a combo with the items listed in myChoices in it.

Personally I think using the choices option is usually better implemented using a separate model and then using a relationship field. If you are really sure the choices list will never change, you could use it. Let me show you how we would rather implement the choice using a second model and a relationship field.

Relationship fields are used to express foreign key joins — you can have one-to-many, many-to-many etc. type relationships. The underlying ‘plumbing’ of these relationships is built for you in the backend database by Django.

First delete the myChoices. line we created above. Next add a new class to models.py (put it before the doodle class) that looks like this:

This is a good use case for using :file:`initial_data.json` fixtures — when you want to be sure that the application or test environment is always initialised with your lookup lists populated.

Next, change the :keyword:`Doodle.name` field from a charfield to one that looks like this:

And add Doodle.type like this:

If you want to, you can specify a default value across the ForeignKey relate by doing e.g.:

(which uses the first instance of doodle type as the default value).

To register the changes in our models, you need to run syncdb again. However we have changed an existing model’s field type ( :keyword:`Doodle.name` ) which means that model’s table definition also needs to be synced to the database. Before we can do that we need to drop its table. We will discuss later how to deal with data that may be in a table if you need to replace it with one that contains existing functionality. For sqlite, just use the sqliteman application to select the table then delete it.

If you are using postgresql as a backend you can do:

To manage the new model, we need to add a new entry to :file:`doodle_app/admin.py` :

If you go back to your doodle admin interface now it should look something like this:

You will notice there is now a little + icon next to the Name field. If you click on it, the admin interface will pop up a form where you can manage the list of names in the DoodleType model.

Whenever we add a new feature like this (changing models, adding new models), we should run our tests and update them if needed or address the causes of failures. Let’s see what happens when we run our tests with the above changes:

You can see our test has immediately informed us that our changes have broken our application! This is useful because we get to fix it instead of perhaps finding out after the changes have been deployed into production.

The critical error meessage above is this:

This is actually good news — it is Django refusing to load the Doodles from the fixture because they don’t have valid related DoodleTypes. To address this we will do the following:

• Create some doodle type entries in the admin interface
• Generate fixtures for :file:`initial_data.json` that will populate the DoodleType model with a few entries.
• Update our test fixtures for Doodle
• Rerun the tests and check that they pass.

Here is how I created the initial_data.json fixture after adding some DoodleType’s in the admin interface:

Then I updated my test fixture ( :file:`doodle_app/fixtures/test_data.json` ), assigning a foreign key reference for all of the Doodle records and updating the doodle names e.g.:

We also need to update our test for Doodle so that doodle_type gets initialised:

The updated test tries to create a DoodleType instance and assign it to the Doodle instance before the Doodle is saved.

There are various strategies to deal with changes to the underlying models in django. Here are the three that I make use of:

• Drop the data in the modified table, drop the table and rerun syncdb. This is useful when you don’t care about the existing data.
• Use sql to manually change the underlying database to keep it in sync with your models.
• Use a tool like South to automate migrations.

Wherever possible, I make use of South, but in the interests of simplicity I am not covering it here.

Let’s verify that our updated test runs now.:

I would like to empahasise the difference between :file:`initial_data.json` and :file:`test_data.json` :

is a production fixtire. It is restored into the database every time you run syncdb (and consequently it is also restored when you run any test). It is useful for prepopulating the database with lookup lists and perhaps user accounts. is a test fixture (you can name this whatever you like and have multiple test fixtures to provide for different scenarios). You reference one or more test fixtures in your unit test, effectively telling your test class what test data should be used while running the tests.

If you were alert, you might have wondered what is to prevent the same DoodleType name being added twice. In fact django automatically takes care of this for you. If you are using a backend like postgresql, django will also add a unique constraint to that field:

So you will see in the next snippet what would happen if you try to insert a duplicate record:

Once again django just takes care of stuff for you in the background and you don’t need to worry about too many small details.

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

Если модель определена вне приложения в INSTALLED_APPS , она должна объявить, к какому приложению она принадлежит:

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

base_manager_name ¶

Имя атрибута менеджера, например ‘objects’ , для использования в модели _base_manager .

db_table ¶

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

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

Чтобы сэкономить ваше время, Django автоматически извлекает имя таблицы базы данных из имени вашего класса модели и приложения, которое его содержит. Имя таблицы базы данных модели создается путем присоединения «метки приложения» модели — имени, которое вы использовали в — к имени класса модели, с подчеркиванием между ними. 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 :

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

db_tablespace ¶

Имя табличного пространства базы данных, которое будет использоваться для этой модели. По умолчанию это настройка проекта DEFAULT_TABLESPACE , если она установлена. Если серверная часть не поддерживает табличные пространства, этот параметр игнорируется.

default_manager_name ¶

Имя менеджера, используемого для модели _default_manager .

default_related_name ¶

Имя, которое будет использоваться по умолчанию для отношения от связанного объекта к этому. По умолчанию это <model_name>_set .

Эта опция также устанавливается related_query_name .

Поскольку обратное имя поля должно быть уникальным, будьте осторожны, если вы собираетесь создать подкласс своей модели. Чтобы обойти конфликты имен, часть имени должна содержать ‘%(app_label)s’ и ‘%(model_name)s’ , которые заменяются соответственно именем приложения, в котором находится модель, и именем модели, оба в нижнем регистре. См. Параграф о связанных именах абстрактных моделей .

get_latest_by ¶

Имя поля или список имен полей в модели, как правило DateField , DateTimeField или IntegerField . Это определяет поле по умолчанию (ы) для использования в модели Manager «ы latest() и earliest() методы.

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

managed ¶

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

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

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

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

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

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

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

order_with_respect_to ¶

Делает этот объект упорядочиваемым относительно данного поля, обычно ForeignKey . Это можно использовать для упорядочивания связанных объектов по отношению к родительскому объекту. Например, если Answer относится к Question объекту, а вопрос имеет более одного ответа, и порядок ответов имеет значение, вы должны сделать следующее:

Когда order_with_respect_to установлено, предоставляются два дополнительных метода для извлечения и установки порядка связанных объектов: get_RELATED_order() и set_RELATED_order() , где RELATED — имя модели в нижнем регистре. Например, предполагая, что у Question объекта есть несколько связанных Answer объектов, возвращаемый список содержит первичные ключи связанных Answer объектов:

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

Связанные объекты также получают два метода, get_next_in_order() и get_previous_in_order() , которые можно использовать для доступа к этим объектам в их правильном порядке. Предполагая, что Answer объекты упорядочены по id :

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 .

ordering ¶

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

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

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

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

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

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

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

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

permissions ¶

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

Это список или кортеж из двух кортежей в формате . (permission_code, human_readable_permission_name)

default_permissions ¶

По умолчанию . Вы можете настроить этот список, например, установив для него пустой список, если вашему приложению не требуются какие-либо разрешения по умолчанию. Он должен быть указан в модели до создания модели , чтобы предотвратить создание любых пропущенных разрешений. (‘add’, ‘change’, ‘delete’, ‘view’) migrate

proxy ¶

Если модель, которая является подклассом другой модели, будет рассматриваться как прокси-модель . proxy = True

required_db_features ¶

Список функций базы данных, которые должно иметь текущее соединение, чтобы модель учитывалась на этапе миграции. Например, если вы установите для этого списка значение [‘gis_enabled’] , модель будет синхронизироваться только в базах данных с поддержкой ГИС. Также полезно пропустить некоторые модели при тестировании с несколькими базами данных. Избегайте отношений между моделями, которые могут или не могут быть созданы, поскольку ORM не справляется с этим.

required_db_vendor ¶

Имя поддерживаемого поставщика базы данных, для которого предназначена данная модель. Текущий встроенные имена поставщиков являются: sqlite , postgresql , mysql , oracle . Если этот атрибут не пуст и текущий поставщик подключения не соответствует ему, модель не будет синхронизирована.

select_on_save ¶

Определяет, будет ли Django использовать django.db.models.Model.save() алгоритм до 1.6 . Старый алгоритм использует, SELECT чтобы определить, есть ли существующая строка для обновления. Новый алгоритм пытается UPDATE напрямую. В некоторых редких случаях UPDATE Django не видит существующую строку. Примером может служить триггер PostgreSQL, который возвращает . В таких случаях новый алгоритм будет работать, даже если в базе данных есть строка. ON UPDATE NULL INSERT

Обычно этот атрибут устанавливать не нужно. По умолчанию это False .

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

indexes ¶

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

unique_together ¶

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

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

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

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

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

А ManyToManyField не может быть включен в unique_toght. (Непонятно, что это вообще может значить!) Если вам нужно проверить уникальность, связанную с a ManyToManyField , попробуйте использовать сигнал или явную through модель.

ValidationError Поднятый во время проверки модели , когда ограничение нарушается , имеет unique_together код ошибки.

index_together ¶

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

Более новый indexes вариант предоставляет больше функциональных возможностей, чем index_together . index_together может быть упразднен в будущем.

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

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

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

constraints ¶

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

verbose_name ¶

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

Если это не указано, Django будет использовать измененную версию имени класса: CamelCase становится . camel case