This document explains all the possible metadata options that you can give your model in its internal
If a model is defined outside of an application in
INSTALLED_APPS, it must declare which app it belongs to:
app_label = 'myapp'
If you want to represent a model with the format
app_label.model_name you can use
The name of the database table to use for the model:
db_table = 'music_album'
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.
For example, if you have an app
bookstore (as created by
manage.py startapp bookstore), a model defined as
class Book will have
a database table named
To override the database table name, use the
db_table parameter in
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 MySQL
It is strongly advised that you use lowercase table names when you override
the table name via
db_table, particularly if you are using the MySQL
backend. 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 shorten
table names and turn them all-uppercase. To prevent such transformations,
use a quoted name as the value for
db_table = '"name_left_in_lowercase"'
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.
True, meaning Django will create the appropriate database
migrate or as part of migrations and remove them as
part of a
flush management command. That is, Django
manages the database tables’ lifecycles.
False, no database table creation or deletion operations will be
performed for this model. This is useful if the model represents an existing
table or a database view that has been created by some other means. This is
the only difference when
managed=False. All other aspects of
model handling are exactly the same as normal. This includes
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
ManyToManyField.through attribute to make the relation
use your custom model.
For tests involving models with
managed=False, it’s up to you to ensure
the 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: Proxy models.
Makes this object orderable with respect to the given field, usually a
ForeignKey. This can be used to make related objects orderable with
respect to a parent object. For example, if an
Answer relates to a
Question object, and a question has more than one answer, and the order
of answers matters, you’d do this:
from django.db import models class Question(models.Model): text = models.TextField() # ... class Answer(models.Model): question = models.ForeignKey(Question, on_delete=models.CASCADE) # ... class Meta: order_with_respect_to = 'question'
order_with_respect_to is set, two additional methods are provided to
retrieve and to set the order of the related objects:
RELATED is the lowercased model name. For
example, assuming that a
Question object has multiple related
objects, the list returned contains the primary keys of the related
>>> question = Question.objects.get(id=1) >>> question.get_answer_order() [1, 2, 3]
The order of a
Question object’s related
Answer objects can be set by
passing in a list of
Answer primary keys:
>>> question.set_answer_order([3, 1, 2])
The related objects also get two methods,
get_previous_in_order(), which can be used to access those objects in their
proper order. Assuming the
Answer objects are ordered by
>>> answer = Answer.objects.get(id=2) >>> answer.get_next_in_order() <Answer: 3> >>> answer.get_previous_in_order() <Answer: 1>
order_with_respect_to implicitly sets the
order_with_respect_to adds an additional field/database
_order and sets the model’s
option to this field. Consequently,
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.
order_with_respect_to adds a new database column, be sure to
make and apply the appropriate migrations if you add or change
order_with_respect_to after your initial
The default ordering for the object, for use when obtaining lists of objects:
ordering = ['-order_date']
This is a tuple or list of strings. 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:
ordering = ['pub_date']
To order by
pub_date descending, use this:
ordering = ['-pub_date']
To order by
pub_date descending, then by
author ascending, use this:
ordering = ['-pub_date', 'author']
Default ordering also affects aggregation queries.
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.
Extra permissions to enter into the permissions table when creating this object.
Add, delete and change permissions are automatically created for each
model. This example specifies an extra permission,
permissions = (("can_deliver_pizzas", "Can deliver pizzas"),)
This is a list or tuple of 2-tuples in the format
('add', 'change', 'delete'). You may customize this list,
for example, by setting this to an empty list if your app doesn’t require
any of the default permissions. It must be specified on the model before
the model is created by
migrate in order to prevent any omitted
permissions from being created.
List of database features that the current connection should have so that
the model is considered during the migration phase. For example, if you set
this list to
['gis_enabled'], the model will only be synchronized on
GIS-enabled databases. It’s also useful to skip some models when testing
with several database backends. Avoid relations between models that may or
may not be created as the ORM doesn’t handle this.
Name of a supported database vendor that this model is specific to. Current
built-in vendor names are:
oracle. If this attribute is not empty and the current connection vendor
doesn’t match it, the model will not be synchronized.
Determines if Django will use the pre-1.6
django.db.models.Model.save() algorithm. The old algorithm
SELECT to determine if there is an existing row to be updated.
The new algorithm tries an
UPDATE directly. In some rare cases the
UPDATE of an existing row isn’t visible to Django. An example is the
ON UPDATE trigger which returns
NULL. In such cases the
new algorithm will end up doing an
INSERT even when a row exists in
Usually there is no need to set this attribute. The default is
django.db.models.Model.save() for more about the old and
new saving algorithm.
A list of indexes that you want to define on the model:
from django.db import models class Customer(models.Model): first_name = models.CharField(max_length=100) last_name = models.CharField(max_length=100) class Meta: indexes = [ models.Index(fields=['last_name', 'first_name']), models.Index(fields=['first_name'], name='first_name_idx'), ]
Sets of field names that, taken together, must be unique:
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., the
UNIQUE statements are included in the
For convenience, unique_together can be a single tuple when dealing with a single set of fields:
unique_together = ("driver", "restaurant")
ManyToManyField cannot be included in
unique_together. (It’s not clear what that would even mean!) If you
need to validate uniqueness related to a
ManyToManyField, try using a signal or
ValidationError raised during model validation when the constraint
is violated has the
unique_together error code.
Sets of field names that, taken together, are indexed:
index_together = [ ["pub_date", "deadline"], ]
This list of fields will be indexed together (i.e. the appropriate
CREATE INDEX statement will be issued.)
index_together can be a single list when dealing with a single
set of fields:
index_together = ["pub_date", "deadline"]
A human-readable name for the object, singular:
verbose_name = "pizza"
If this isn’t given, Django will use a munged version of the class name: