Django Model meta Options

Available forMetaOptionsAbstract

Options. Abstract

If abstract = True , the model is an abstract base class.

App_label

Options. App_label

If a model is defined outside the default models.py (for example, if your app's models is under the myapp.models submodule), you must define App_label to let Django know that it belongs to Which app

' MyApp '

db_table

Options. db_table

Define the table name of the model in the data:

' Music_album '

Table names in the database

To save time, Django automatically uses the name of your model class and the name of the app that contains the model to build the table name of the database. A model database table name is formed by adding "app label" – The name you use in manage.py Startapp – and the model class name, plus an underscore between them.

For example, if you have an app called bookstore (created with manage.py startapp bookstore ), and a model is defined as cl This will create a database table named Bookstore_book .

If you want to customize the table name of the database, you need to customize it using the db_table parameter in class Meta .

This is fine if your database table name is a SQL reserved word, or it contains characters that are not allowed in Python variables (such as hyphens). This is because Django automatically adds quotation marks to the column name and table name.

Use lowercase letters as database table names in MySQL

It is strongly recommended that you use lowercase letters when overloading database table names through db_table , especially if you are using MySQL as a background database. Check out MySQL notes for more details.

Db_tablespace

Options. Db_tablespace

Defines the database table space used by this model. If default_tablespace is defined in the setting of the project, then it will use this value. This option is ignored if the background database does not support table spaces.

get_latest_by

Options. get_latest_by

Specify a Datefield or Datetimefield in the model. This setting allows you to sort by default using the specified field when using the latest method on the model's Manager .

For example:

"Order_date"

See latest () .

managed

Options. managed

The default value is True , which means that Django can use the syncdb and reset commands to create or remove the corresponding database. In other words, Django manages the life cycle of the database.

If set to False , Django will not create or delete database tables for the current model. This is often useful when representing an existing data table that is created by another method. This is the only difference when managed=false . Model is exactly the same when it comes to dealing with everything else. This includes

1. If you do not declare a primary key field, Django automatically adds a self-incremented primary key field to the model. When you use a models that is not managed *, it is recommended that all the fields hosted in model be related to the database table in order to avoid confusing the person who will read the code in the future.

2. If a Manytomanyfield Association is used between two unmanaged models (Managed=false), an intermediate table of many-to-many relationships is not created. However, if it is a managed model and another unmanaged model, many-to-many relationships will be created.

   If you need to change the default behavior, create an intermediate table in the database (to set the managed to True), and then use it on your original model by displaying the middle model of the definition The Manytomanyfield.through attribute points to the middle model, enabling you to implement a custom many-to-many relationship.

If your test contains an unmanaged model (Managed=false), you should make sure that you have created the correct data table at the time of test creation before testing.

If you want to change the behavior of a Python level in the Model class, you can make managed=false and then create a copy of the model to define the new behavior in the copy. However, in the face of this situation there is a better way is to use Proxy models.

order_with_respect_to

Options. order_with_respect_to

Sorts the model according to the given field. In an association relationship, it is often used where the source object is sorted according to the target object. For example, a Answer is associated with only one Question object, while a Question object can have multiple Answer objects associated with it. You should do this by sorting answer according to question:

 class answer (models.model): question = models foreignkey (question) # ... class meta: order_with_respect_to = Span class= "s" > ' question '             

When  order_with_respect_to   is set, two additional methods are provided to get and set the ordering of the associated objects: get_related_order ()   and  set_related_order () &NBSP, this one of the  related   is the lowercase name of the model. For example, suppose a question   object is associated to more than one  answer   object, which returns a list containing  answer   Object primary key:

Question.  Objects.  Get(id=1)question.  Get_answer_order()[1, 2, 3]             

You can set the order of the Answer objects associated with the Question object by passing in a list of Answer primary keys:

Question.  Set_answer_order([312])      

The associated object also has two methods, Get_next_in_order () and Get_previous_in_order () , which can be used to access those specific objects. Assume that the Answer object is sorted by ID :

Answer.  Objects.  Get(id=2)answer.  Get_next_in_order()<Answer:3>Answer.  Get_previous_in_order()<Answer:1>          

Notice when changing order_with_respect_to

order_with_respect_to Adds a field called _order (database field), so if you add or change the Order_ after you perform the syncdb operation With_respect_to Make sure you handle it properly.

Ordering

Options. Ordering

Defines the default ordering of objects when getting a list of objects:

['-order_date '] 

This is a string of tuples or lists. None of the strings consist of a field name and an optional "-" prefix that indicates descending. When the field name does not precede "-", it is used by default in ascending order. Using "?" will be arranged randomly.

For example, the pub_date word orderby order is available:

[' Pub_date '] 

When sorted in descending order of Pub_date , available:

['-pub_date '] 

In descending order of pub_date , and then in ascending order of author , available:

['-pub_date 'author ']  

Changed in Django 1.4:django admin takes all the elements in the list/tuple, and only the first element is adopted before version 1.4.

Permissions

Options. Permissions

Additional permission information added to the permissions table when the object is created. Django automatically creates the added, deleted, and modified permissions for each object that has the admin set. The following example shows how to add an additional permission Can_deliver_pizzas:

("Can_deliver_pizzas" "can Deliver Pizzas"),)  

The item can be a list or a tuple of two tuples in such a format (Permission_code, human_readable_permission_name) .

Proxy

Options. Proxy

If proxy = True , indicates that the model is the proxy model of its parent class.

Unique_together

Options. Unique_together

The combination of the fields that are used to set the duplicates must be unique (the two fields are federated only):

("Driver" ("Restaurant"),)  

It is a list of field names, the combination of fields in the list is unique in the database, not duplicates, that is, there can be no two objects, and their field values in the list are exactly the same. It is used in the Django admin background to constrain data at the database level. (for example, include a UNIQUE keyword in the CREATE TABLE statement)

For ease of use, you can assign a tuple of a separate field list to the item:

("Driver" "Restaurant")  

A Manytomanyfield cannot be included in the Unique_together . (This will cause it to look shady!) If you need to verify the uniqueness validation associated to the manytomanyfield field, try using signal (signal) or explicitly specifying the through property of the model.

Verbose_name

Options. Verbose_name

Specify an object name that is easy to understand and express, in singular form:

"Pizza"

If this value is not set, Django will use the word-breaker form of the model's class name as his object expression name: CamelCase will be converted to camel case.

verbose_name_plural

Options. verbose_name_plural

The plural expression name of the object:

"Stories"

If not specified, Django uses the form verbose_name + "s" as the expression name of the object.

Django Model meta Options