Model Meta options

    • Options.abstract
    • If abstract = True, this model will be an.

    app_label

    • Options.app_label
    • If a model is defined outside of an application inINSTALLED_APPS, it must declare which app it belongs to:

    If you want to represent a model with the format app_label.object_nameor app_label.model_name you can use model._meta.labelor model._meta.label_lower respectively.

    base_manager_name

    • Options.base_manager_name
    • The name of the manager to use for the model's.

    db_table

    • Options.db_table
    • The name of the database table to use for the model:
    1. db_table = 'music_album'

    Table names

    To save you time, Django automatically derives the name of the database tablefrom the name of your model class and the app that contains it. A model'sdatabase table name is constructed by joining the model's "app label" — thename you used in — to the model'sclass name, with an underscore between them.

    For example, if you have an app bookstore (as created bymanage.py startapp bookstore), a model defined as class Book will havea database table named bookstore_book.

    To override the database table name, use the db_table parameter inclass Meta.

    If your database table name is an SQL reserved word, or contains characters thataren'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 MySQL

    It is strongly advised that you use lowercase table names when you overridethe table name via db_table, particularly if you are using the MySQLbackend. See the MySQL notes for more details.

    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 shortentable names and turn them all-uppercase. To prevent such transformations,use a quoted name as the value for db_table:

    1. db_table = '"name_left_in_lowercase"'

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

    db_tablespace

    • Options.db_tablespace
    • The name of the database tablespace to usefor this model. The default is the project's setting, if set. If the backend doesn't support tablespaces, this option isignored.

    default_manager_name

    • Options.default_manager_name
    • Options.default_related_name
    • The name that will be used by default for the relation from a related objectback to this one. The default is <model_name>_set.

    This option also sets related_query_name.

    As the reverse name for a field should be unique, be careful if you intendto subclass your model. To work around name collisions, part of the nameshould contain '%(app_label)s' and '%(model_name)s', which arereplaced respectively by the name of the application the model is in,and the name of the model, both lowercased. See the paragraph on.

    get_latest_by

    • Options.get_latest_by
    • The name of a field or a list of field names in the model, typicallyDateField, , or IntegerField. Thisspecifies the default field(s) to use in your model ’slatest() and methods.

    Example:

    1. # Latest by ascending order_date.
    2. get_latest_by = "order_date"
    3.  
    4. # Latest by priority descending, order_date ascending.
    5. get_latest_by = ['-priority', 'order_date']

    See the latest() docs for more.

    • Options.managed
    • Defaults to True, meaning Django will create the appropriate databasetables in migrate or as part of migrations and remove them aspart of a management command. That is, Djangomanages the database tables' lifecycles.

    If False, no database table creation or deletion operations will beperformed for this model. This is useful if the model represents an existingtable or a database view that has been created by some other means. This isthe only difference when managed=False. All other aspects ofmodel handling are exactly the same as normal. This includes

    • Adding an automatic primary key field to the model if you don'tdeclare it. To avoid confusion for later code readers, it'srecommended to specify all the columns from the database table youare modeling when using unmanaged models.

    • If a model with managed=False contains aManyToManyField that points to anotherunmanaged model, then the intermediate table for the many-to-manyjoin will also not be created. However, the intermediary tablebetween one managed and one unmanaged model will be created.

    For tests involving models with , it's up to you to ensurethe correct tables are created as part of the test setup.

    If you're interested in changing the Python-level behavior of a model class,you could use managed=False and create a copy of an existing model.However, there's a better approach for that situation: .

    order_with_respect_to

    • Options.order_with_respect_to
    • Makes this object orderable with respect to the given field, usually aForeignKey. This can be used to make related objects orderable withrespect to a parent object. For example, if an Answer relates to aQuestion object, and a question has more than one answer, and the orderof answers matters, you'd do this:
    1. from django.db import models
    2.  
    3. class Question(models.Model):
    4.     text = models.TextField()
    5.     # ...
    6.  
    7. class Answer(models.Model):
    8.     question = models.ForeignKey(Question, on_delete=models.CASCADE)
    9.     # ...
    10.  
    11.     class Meta:
    12.         order_with_respect_to = 'question'

    When order_with_respect_to is set, two additional methods are provided toretrieve and to set the order of the related objects: get_RELATED_order()and set_RELATED_order(), where RELATED is the lowercased model name. Forexample, assuming that a Question object has multiple related Answerobjects, the list returned contains the primary keys of the related Answerobjects:

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

    The order of a Question object's related Answer objects can be set bypassing in a list of Answer primary keys:

    1. >>> question.set_answer_order([3, 1, 2])

    The related objects also get two methods, get_next_in_order() andget_previous_in_order(), which can be used to access those objects in theirproper order. Assuming the Answer objects are ordered by id:

    order_with_respect_to implicitly sets the ordering option

    Internally, order_with_respect_to adds an additional field/databasecolumn named _order and sets the model's orderingoption to this field. Consequently, order_with_respect_to andordering cannot be used together, and the ordering added byorder_with_respect_to will apply whenever you obtain a list of objectsof this model.

    Changing order_with_respect_to

    Because order_with_respect_to adds a new database column, be sure tomake and apply the appropriate migrations if you add or changeorder_with_respect_to after your initial .

    ordering

    • Options.ordering
    • The default ordering for the object, for use when obtaining lists of objects:
    1. ordering = ['-order_date']

    This is a tuple or list of strings and/or query expressions. Each string isa 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:

    1. ordering = ['pub_date']

    To order by pub_date descending, use this:

    1. ordering = ['-pub_date']

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

    1. ordering = ['-pub_date', 'author']

    You can also use query expressions. Toorder by author ascending and make null values sort last, use this:

    1. from django.db.models import F
    2.  
    3. ordering = [F('author').asc(nulls_last=True)]

    Default ordering also affects but this won't be the case startingin Django 3.1.

    警告

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

    permissions

    • Options.permissions
    1. permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)

    This is a list or tuple of 2-tuples in the format (permission_code,
    human_readable_permission_name)    .

    default_permissions

    • Options.default_permissions
    • Defaults to ('add', 'change', 'delete', 'view'). You may customize thislist, for example, by setting this to an empty list if your app doesn'trequire any of the default permissions. It must be specified on the modelbefore the model is created by migrate in order to prevent anyomitted permissions from being created.

    Changed in Django 2.1:
    The view permission was added.

    proxy

    • Options.proxy
    • If proxy = True, a model which subclasses another model will be treated asa .

    required_db_features

    • Options.required_db_features
    • List of database features that the current connection should have so thatthe model is considered during the migration phase. For example, if you setthis list to ['gis_enabled'], the model will only be synchronized onGIS-enabled databases. It's also useful to skip some models when testingwith several database backends. Avoid relations between models that may ormay not be created as the ORM doesn't handle this.

    required_db_vendor

    • Options.
    • Name of a supported database vendor that this model is specific to. Currentbuilt-in vendor names are: sqlite, postgresql, mysql,oracle. If this attribute is not empty and the current connection vendordoesn't match it, the model will not be synchronized.
    • Options.select_on_save
    • Determines if Django will use the pre-1.6 algorithm. The old algorithmuses SELECT to determine if there is an existing row to be updated.The new algorithm tries an UPDATE directly. In some rare cases theUPDATE of an existing row isn't visible to Django. An example is thePostgreSQL ON UPDATE trigger which returns NULL. In such cases thenew algorithm will end up doing an INSERT even when a row exists inthe database.

    Usually there is no need to set this attribute. The default isFalse.

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

    indexes

    • Options.indexes
    • A list of that you want to define onthe model:

    unique_together

    • Options.unique_together

    Use UniqueConstraint with the option instead.

    UniqueConstraint provides more functionality thanunique_together. unique_together may be deprecated in thefuture.

    Sets of field names that, taken together, must be unique:

    1. unique_together = (("driver", "restaurant"),)

    This is a tuple of tuples that must be unique when considered together.It's used in the Django admin and is enforced at the database level (i.e., theappropriate UNIQUE statements are included in the CREATE TABLEstatement).

    For convenience, unique_together can be a single tuple when dealing with a singleset of fields:

    1. unique_together = ("driver", "restaurant")

    A cannot be included inunique_together. (It's not clear what that would even mean!) If youneed to validate uniqueness related to aManyToManyField, try using a signal oran explicit model.

    The ValidationError raised during model validation when the constraintis violated has the unique_together error code.

    index_together

    • Options.index_together

    Use the indexes option instead.

    The newer option provides more functionalitythan index_together. index_together may be deprecated in thefuture.

    Sets of field names that, taken together, are indexed:

    1. index_together = [
    2.     ["pub_date", "deadline"],
    3. ]

    This list of fields will be indexed together (i.e. the appropriateCREATE INDEX statement will be issued.)

    For convenience, index_together can be a single list when dealing with a singleset of fields:

    1. index_together = ["pub_date", "deadline"]

    constraints

    • Options.constraints
    • New in Django 2.2:

    A list of constraints that you want todefine on the model:

    1. from django.db import models
    2.  
    3. class Customer(models.Model):
    4.     age = models.IntegerField()
    5.  
    6.     class Meta:
    7.         constraints = [
    8.             models.CheckConstraint(check=models.Q(age__gte=18), name='age_gte_18'),
    9.         ]

    verbose_name

    • Options.verbose_name
    • A human-readable name for the object, singular:
    1. verbose_name = "pizza"

    verbose_name_plural

    • Options.verbose_name_plural
    • The plural name for the object:

    If this isn't given, Django will use + "s".

    Read-only Meta attributes

    label

    • Options.label
    • Representation of the object, returns app_label.object_name, e.g.'polls.Question'.
    • Representation of the model, returns app_label.model_name, e.g..