Meta optionsLink to this heading#This document explains all the possible metadata options that you can give your model in its internal\nclass Meta.
Meta optionsLink to this heading#abstractLink to this heading#If abstract = True, this model will be an\nabstract base class.
app_labelLink to this heading#If a model is defined outside of an application in\nINSTALLED_APPS, it must declare which app it belongs to:
app_label = "myapp"\nIf you want to represent a model with the format app_label.object_name\nor app_label.model_name you can use model._meta.label\nor model._meta.label_lower respectively.
base_manager_nameLink to this heading#The attribute name of the manager, for example, 'objects', to use for\nthe model’s _base_manager.
db_tableLink to this heading#The name of the database table to use for the model:
\ndb_table = "music_album"\nTo save you time, Django automatically derives the name of the database table\nfrom the name of your model class and the app that contains it. A model’s\ndatabase table name is constructed by joining the model’s «app label» – the\nname you used in manage.py startapp – to the model’s\nclass name, with an underscore between them.
For example, if you have an app bookstore (as created by\nmanage.py startapp bookstore), a model defined as class Book will have\na database table named bookstore_book.
To override the database table name, use the db_table parameter in\nclass Meta.
If your database table name is an SQL reserved word, or contains characters\nthat aren’t allowed in Python variable names – notably, the hyphen – that’s\nOK. Django quotes column and table names behind the scenes.
\n\n\ndb_table_commentLink to this heading#The comment on the database table to use for this model. It is useful for\ndocumenting database tables for individuals with direct database access who may\nnot be looking at your Django code. For example:
\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n answer = models.TextField()\n\n class Meta:\n db_table_comment = "Question answers"\ndb_tablespaceLink to this heading#The name of the database tablespace to use\nfor this model. The default is the project’s DEFAULT_TABLESPACE\nsetting, if set. If the backend doesn’t support tablespaces, this option is\nignored.
default_manager_nameLink to this heading#The name of the manager to use for the model’s\n_default_manager.
get_latest_byLink to this heading#The name of a field or a list of field names in the model, typically\nDateField, DateTimeField, or IntegerField. This\nspecifies the default field(s) to use in your model Manager’s\nlatest() and\nearliest() methods.
Example:
\n# Latest by ascending order_date.\nget_latest_by = "order_date"\n\n# Latest by priority descending, order_date ascending.\nget_latest_by = ["-priority", "order_date"]\nSee the latest() docs for more.
managedLink to this heading#Defaults to True, meaning Django will create the appropriate database\ntables in migrate or as part of migrations and remove them as\npart of a flush management command. That is, Django\nmanages the database tables” lifecycles.
If False, no database table creation, modification, or deletion\noperations will be performed for this model. This is useful if the model\nrepresents an existing table or a database view that has been created by\nsome other means. This is the only difference when managed=False. All\nother aspects of model handling are exactly the same as normal. This\nincludes
Adding an automatic primary key field to the model if you don’t\ndeclare it. To avoid confusion for later code readers, it’s\nrecommended to specify all the columns from the database table you\nare modeling when using unmanaged models.
If a model with managed=False contains a\nManyToManyField that points to another\nunmanaged model, then the intermediate table for the many-to-many\njoin will also not be created. However, the intermediary table\nbetween one managed and one unmanaged model will be created.
If you need to change this default behavior, create the intermediary\ntable as an explicit model (with managed set as needed) and use\nthe ManyToManyField.through attribute to make the relation\nuse your custom model.
For tests involving models with managed=False, it’s up to you to ensure\nthe correct tables are created as part of the test setup.
If you’re interested in changing the Python-level behavior of a model\nclass, you could use managed=False and create a copy of an existing\nmodel. However, there’s a better approach for that situation:\nProxy models.
order_with_respect_toLink to this heading#Makes this object orderable with respect to the given field, usually a\nForeignKey. This can be used to make related objects orderable with\nrespect to a parent object. For example, if an Answer relates to a\nQuestion object, and a question has more than one answer, and the order\nof answers matters, you’d do this:
from django.db import models\n\n\nclass Question(models.Model):\n text = models.TextField()\n # ...\n\n\nclass Answer(models.Model):\n question = models.ForeignKey(Question, on_delete=models.CASCADE)\n # ...\n\n class Meta:\n order_with_respect_to = "question"\nWhen order_with_respect_to is set, two additional methods are provided\nto retrieve and to set the order of the related objects:\nget_RELATED_order() and set_RELATED_order(), where RELATED is\nthe lowercased model name. For example, assuming that a Question object\nhas multiple related Answer objects, the list returned contains the\nprimary keys of the related Answer objects:
>>> question = Question.objects.get(id=1)\n>>> question.get_answer_order()\n[1, 2, 3]\nThe order of a Question object’s related Answer objects can be set\nby passing in a list of Answer primary keys:
>>> question.set_answer_order([3, 1, 2])\nThe related objects also get two methods, get_next_in_order() and\nget_previous_in_order(), which can be used to access those objects in\ntheir proper order. Assuming the Answer objects are ordered by id:
>>> answer = Answer.objects.get(id=2)\n>>> answer.get_next_in_order()\n<Answer: 3>\n>>> answer.get_previous_in_order()\n<Answer: 1>\norderingLink to this heading#The default ordering for the object, for use when obtaining lists of\nobjects:
\nordering = ["-order_date"]\nThis is a tuple or list of strings and/or query expressions. Each string is\na field name with an optional «-» prefix, which indicates descending order.\nFields without a leading «-» will be ordered ascending. Use the string «?»\nto order randomly.
\nFor example, to order by a pub_date field ascending, use this:
ordering = ["pub_date"]\nTo order by pub_date descending, use this:
ordering = ["-pub_date"]\nTo order by pub_date descending, then by author ascending, use\nthis:
ordering = ["-pub_date", "author"]\nYou can also use query expressions. To\norder by author ascending and make null values sort last, use this:
from django.db.models import F\n\nordering = [F("author").asc(nulls_last=True)]\npermissionsLink to this heading#Extra permissions to enter into the permissions table when creating this\nobject. Add, change, delete, and view permissions are automatically created\nfor each model. This example specifies an extra permission,\ncan_deliver_pizzas:
permissions = [("can_deliver_pizzas", "Can deliver pizzas")]\nThis is a list or tuple of 2-tuples in the format (permission_code,\nhuman_readable_permission_name).
default_permissionsLink to this heading#Defaults to ('add', 'change', 'delete', 'view'). You may customize this\nlist, for example, by setting this to an empty list if your app doesn’t\nrequire any of the default permissions. It must be specified on the model\nbefore the model is created by migrate in order to prevent any\nomitted permissions from being created.
proxyLink to this heading#If proxy = True, a model which subclasses another model will be treated\nas a proxy model.
required_db_featuresLink to this heading#List of database features that the current connection should have so that\nthe model is considered during the migration phase. For example, if you set\nthis list to ['gis_enabled'], the model will only be synchronized on\nGIS-enabled databases. It’s also useful to skip some models when testing\nwith several database backends. Avoid relations between models that may or\nmay not be created as the ORM doesn’t handle this.
required_db_vendorLink to this heading#Name of a supported database vendor that this model is specific to. Current\nbuilt-in vendor names are: sqlite, postgresql, mysql,\noracle. If this attribute is not empty and the current connection\nvendor doesn’t match it, the model will not be synchronized.
select_on_saveLink to this heading#Determines if Django will use the pre-1.6\ndjango.db.models.Model.save() algorithm. The old algorithm\nuses SELECT to determine if there is an existing row to be updated.\nThe new algorithm tries an UPDATE directly. In some rare cases the\nUPDATE of an existing row isn’t visible to Django. An example is the\nPostgreSQL ON UPDATE trigger which returns NULL. In such cases the\nnew algorithm will end up doing an INSERT even when a row exists in\nthe database.
Usually there is no need to set this attribute. The default is\nFalse.
See django.db.models.Model.save() for more about the old and\nnew saving algorithm.
indexesLink to this heading#A list of indexes that you want to define on\nthe model:
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n first_name = models.CharField(max_length=100)\n last_name = models.CharField(max_length=100)\n\n class Meta:\n indexes = [\n models.Index(fields=["last_name", "first_name"]),\n models.Index(fields=["first_name"], name="first_name_idx"),\n ]\nunique_togetherLink to this heading#Sets of field names that, taken together, must be unique:
\nunique_together = [["driver", "restaurant"]]\nThis is a list of lists that must be unique when considered together.\nIt’s used in the Django admin and is enforced at the database level (i.e.,\nthe appropriate UNIQUE statements are included in the CREATE TABLE\nstatement).
For convenience, unique_together can be a single list when dealing with\na single set of fields:
unique_together = ["driver", "restaurant"]\nA ManyToManyField cannot be included in\nunique_together. (It’s not clear what that would even mean!) If you\nneed to validate uniqueness related to a\nManyToManyField, try using a signal or\nan explicit through model.
The ValidationError raised during model validation when the constraint\nis violated has the unique_together error code.
constraintsLink to this heading#A list of constraints that you want to\ndefine on the model:
\nfrom django.db import models\n\n\nclass Customer(models.Model):\n age = models.IntegerField()\n\n class Meta:\n constraints = [\n models.CheckConstraint(condition=models.Q(age__gte=18), name="age_gte_18"),\n ]\nverbose_nameLink to this heading#A human-readable name for the object, singular:
\nverbose_name = "pizza"\nIf this isn’t given, Django will use a munged version of the class name:\nCamelCase becomes camel case.
verbose_name_pluralLink to this heading#The plural name for the object:
\nverbose_name_plural = "stories"\nIf this isn’t given, Django will use verbose_name +\n"s".
Meta attributesLink to this heading#labelLink to this heading#Representation of the object, returns app_label.object_name, e.g.\n'polls.Question'.
label_lowerLink to this heading#Representation of the model, returns app_label.model_name, e.g.\n'polls.question'.