Model instance reference

This document describes the details of the Model API. It builds on thematerial presented in the model and databasequery guides, so you’ll probably want to read andunderstand those documents before reading this one.

Throughout this reference we’ll use the example Weblog models presented in the database query guide.

Creating objects

To create a new instance of a model, instantiate it like any other Pythonclass:

• class Model(**kwargs)
• The keyword arguments are the names of the fields you’ve defined on your model.Note that instantiating a model in no way touches your database; for that, youneed to save().

Note

You may be tempted to customize the model by overriding the initmethod. If you do so, however, take care not to change the callingsignature as any change may prevent the model instance from being saved.Rather than overriding init, try using one of these approaches:

• Add a classmethod on the model class:

from django.db import models
 
class Book(models.Model):
    title = models.CharField(max_length=100)
 
    @classmethod
    def create(cls, title):
        book = cls(title=title)
        # do something with the book
        return book
 
book = Book.create("Pride and Prejudice")

• Add a method on a custom manager (usually preferred):

class BookManager(models.Manager):
    def create_book(self, title):
        book = self.create(title=title)
        # do something with the book
        return book
 
class Book(models.Model):
    title = models.CharField(max_length=100)
 
    objects = BookManager()
 
book = Book.objects.create_book("Pride and Prejudice")

Customizing model loading

• classmethod Model.fromdb(_db, field_names, values)
• The from_db() method can be used to customize model instance creationwhen loading from the database.

The db argument contains the database alias for the database the modelis loaded from, fieldnames contains the names of all loaded fields, andvalues contains the loaded values for each field in fieldnames. Thefield_names are in the same order as the values. If all of the model’sfields are present, then values are guaranteed to be in the order__init() expects them. That is, the instance can be created bycls(*values). If any fields are deferred, they won’t appear infield_names. In that case, assign a value of django.db.models.DEFERREDto each of the missing fields.

In addition to creating the new model, the from_db() method must set theadding and db flags in the new instance’s _state attribute.

Below is an example showing how to record the initial values of fields thatare loaded from the database:

from django.db.models import DEFERRED
 
@classmethod
def from_db(cls, db, field_names, values):
    # Default implementation of from_db() (subject to change and could
    # be replaced with super()).
    if len(values) != len(cls._meta.concrete_fields):
        values = list(values)
        values.reverse()
        values = [
            values.pop() if f.attname in field_names else DEFERRED
            for f in cls._meta.concrete_fields
        ]
    instance = cls(*values)
    instance._state.adding = False
    instance._state.db = db
    # customization to store the original field values on the instance
    instance._loaded_values = dict(zip(field_names, values))
    return instance
 
def save(self, *args, **kwargs):
    # Check how the current values differ from ._loaded_values. For example,
    # prevent changing the creator_id of the model. (This example doesn't
    # support cases where 'creator_id' is deferred).
    if not self._state.adding and (
            self.creator_id != self._loaded_values['creator_id']):
        raise ValueError("Updating the value of creator isn't allowed")
    super().save(*args, **kwargs)

The example above shows a full from_db() implementation to clarify how thatis done. In this case it would of course be possible to use super() call inthe from_db() method.

Refreshing objects from database

If you delete a field from a model instance, accessing it again reloads thevalue from the database:

>>> obj = MyModel.objects.first()
>>> del obj.field
>>> obj.field  # Loads the field from the database

• Model.refreshfrom_db(_using=None, fields=None)

• If you need to reload a model’s values from the database, you can use therefresh_from_db() method. When this method is called without arguments thefollowing is done:

• All non-deferred fields of the model are updated to the values currentlypresent in the database.

• Any cached relations are cleared from the reloaded instance.Only fields of the model are reloaded from the database. Otherdatabase-dependent values such as annotations aren’t reloaded. Any@cached_property attributesaren’t cleared either.

The reloading happens from the database the instance was loaded from, or fromthe default database if the instance wasn’t loaded from the database. Theusing argument can be used to force the database used for reloading.

It is possible to force the set of fields to be loaded by using the fieldsargument.

For example, to test that an update() call resulted in the expectedupdate, you could write a test similar to this:

def test_update_result(self):
    obj = MyModel.objects.create(val=1)
    MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)
    # At this point obj.val is still 1, but the value in the database
    # was updated to 2. The object's updated value needs to be reloaded
    # from the database.
    obj.refresh_from_db()
    self.assertEqual(obj.val, 2)

Note that when deferred fields are accessed, the loading of the deferredfield’s value happens through this method. Thus it is possible to customizethe way deferred loading happens. The example below shows how one can reloadall of the instance’s fields when a deferred field is reloaded:

class ExampleModel(models.Model):
    def refresh_from_db(self, using=None, fields=None, **kwargs):
        # fields contains the name of the deferred field to be
        # loaded.
        if fields is not None:
            fields = set(fields)
            deferred_fields = self.get_deferred_fields()
            # If any deferred field is going to be loaded
            if fields.intersection(deferred_fields):
                # then load all of them
                fields = fields.union(deferred_fields)
        super().refresh_from_db(using, fields, **kwargs)

• Model.get_deferred_fields()
• A helper method that returns a set containing the attribute names of all thosefields that are currently deferred for this model.

Validating objects

There are three steps involved in validating a model:

• Validate the model fields - Model.clean_fields()
• Validate the model as a whole - Model.clean()
• Validate the field uniqueness - Model.validate_unique()All three steps are performed when you call a model’sfull_clean() method.

When you use a ModelForm, the call tois_valid() will perform these validation steps forall the fields that are included on the form. See the ModelFormdocumentation for more information. You should onlyneed to call a model’s full_clean() method if you plan to handlevalidation errors yourself, or if you have excluded fields from theModelForm that require validation.

• Model.fullclean(_exclude=None, validate_unique=True)
• This method calls Model.clean_fields(), Model.clean(), andModel.validate_unique() (if validate_unique is True), in thatorder and raises a ValidationError that has amessage_dict attribute containing errors from all three stages.

The optional exclude argument can be used to provide a list of field namesthat can be excluded from validation and cleaning.ModelForm uses this argument to exclude fields thataren’t present on your form from being validated since any errors raised couldnot be corrected by the user.

Note that fullclean() will _not be called automatically when you callyour model’s save() method. You’ll need to call it manuallywhen you want to run one-step model validation for your own manually createdmodels. For example:

from django.core.exceptions import ValidationError
try:
    article.full_clean()
except ValidationError as e:
    # Do something based on the errors contained in e.message_dict.
    # Display them to a user, or handle them programmatically.
    pass

The first step full_clean() performs is to clean each individual field.

• Model.cleanfields(_exclude=None)
• This method will validate all fields on your model. The optional excludeargument lets you provide a list of field names to exclude from validation. Itwill raise a ValidationError if any fields failvalidation.

The second step full_clean() performs is to call Model.clean().This method should be overridden to perform custom validation on your model.

• Model.clean()
• This method should be used to provide custom model validation, and to modifyattributes on your model if desired. For instance, you could use it toautomatically provide a value for a field, or to do validation that requiresaccess to more than a single field:

import datetime
from django.core.exceptions import ValidationError
from django.db import models
from django.utils.translation import gettext_lazy as _
 
class Article(models.Model):
    ...
    def clean(self):
        # Don't allow draft entries to have a pub_date.
        if self.status == 'draft' and self.pub_date is not None:
            raise ValidationError(_('Draft entries may not have a publication date.'))
        # Set the pub_date for published items if it hasn't been set already.
        if self.status == 'published' and self.pub_date is None:
            self.pub_date = datetime.date.today()

Note, however, that like Model.full_clean(), a model’s clean()method is not invoked when you call your model’s save() method.

In the above example, the ValidationErrorexception raised by Model.clean() was instantiated with a string, so itwill be stored in a special error dictionary key,NON_FIELD_ERRORS. This key is used for errorsthat are tied to the entire model instead of to a specific field:

from django.core.exceptions import NON_FIELD_ERRORS, ValidationError
try:
    article.full_clean()
except ValidationError as e:
    non_field_errors = e.message_dict[NON_FIELD_ERRORS]

To assign exceptions to a specific field, instantiate theValidationError with a dictionary, where thekeys are the field names. We could update the previous example to assign theerror to the pub_date field:

class Article(models.Model):
    ...
    def clean(self):
        # Don't allow draft entries to have a pub_date.
        if self.status == 'draft' and self.pub_date is not None:
            raise ValidationError({'pub_date': _('Draft entries may not have a publication date.')})
        ...

If you detect errors in multiple fields during Model.clean(), you can alsopass a dictionary mapping field names to errors:

raise ValidationError({
    'title': ValidationError(_('Missing title.'), code='required'),
    'pub_date': ValidationError(_('Invalid date.'), code='invalid'),
})

Finally, full_clean() will check any unique constraints on your model.

How to raise field-specific validation errors if those fields don’t appear in a ModelForm

You can’t raise validation errors in Model.clean() for fields thatdon’t appear in a model form (a form may limit its fields usingMeta.fields or Meta.exclude). Doing so will raise a ValueErrorbecause the validation error won’t be able to be associated with theexcluded field.

To work around this dilemma, instead override Model.clean_fields() as it receives the list of fieldsthat are excluded from validation. For example:

class Article(models.Model):
    ...
    def clean_fields(self, exclude=None):
        super().clean_fields(exclude=exclude)
        if self.status == 'draft' and self.pub_date is not None:
            if exclude and 'status' in exclude:
                raise ValidationError(
                    _('Draft entries may not have a publication date.')
                )
            else:
                raise ValidationError({
                    'status': _(
                        'Set status to draft if there is not a '
                        'publication date.'
                     ),
                })

• Model.validateunique(_exclude=None)
• This method is similar to clean_fields(), but validates alluniqueness constraints on your model instead of individual field values. Theoptional exclude argument allows you to provide a list of field names toexclude from validation. It will raise aValidationError if any fields fail validation.

Note that if you provide an exclude argument to validate_unique(), anyunique_together constraint involving one ofthe fields you provided will not be checked.

Saving objects

To save an object back to the database, call save():

• Model.save(force_insert=False, force_update=False, using=DEFAULT_DB_ALIAS, update_fields=None)
• If you want customized saving behavior, you can override this save()method. See Overriding predefined model methods for more details.

The model save process also has some subtleties; see the sections below.

Auto-incrementing primary keys

If a model has an AutoField — an auto-incrementingprimary key — then that auto-incremented value will be calculated and saved asan attribute on your object the first time you call save():

>>> b2 = Blog(name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b2.id     # Returns None, because b2 doesn't have an ID yet.
>>> b2.save()
>>> b2.id     # Returns the ID of your new object.

There’s no way to tell what the value of an ID will be before you callsave(), because that value is calculated by your database, not by Django.

For convenience, each model has an AutoField namedid by default unless you explicitly specify primary_key=True on a fieldin your model. See the documentation for AutoFieldfor more details.

The pk property

• Model.pk
• Regardless of whether you define a primary key field yourself, or let Djangosupply one for you, each model will have a property called pk. It behaveslike a normal attribute on the model, but is actually an alias for whicheverattribute is the primary key field for the model. You can read and set thisvalue, just as you would for any other attribute, and it will update thecorrect field in the model.

Explicitly specifying auto-primary-key values

If a model has an AutoField but you want to define anew object’s ID explicitly when saving, define it explicitly before saving,rather than relying on the auto-assignment of the ID:

>>> b3 = Blog(id=3, name='Cheddar Talk', tagline='Thoughts on cheese.')
>>> b3.id     # Returns 3.
>>> b3.save()
>>> b3.id     # Returns 3.

If you assign auto-primary-key values manually, make sure not to use analready-existing primary-key value! If you create a new object with an explicitprimary-key value that already exists in the database, Django will assume you’rechanging the existing record rather than creating a new one.

Given the above 'Cheddar Talk' blog example, this example would override theprevious record in the database:

b4 = Blog(id=3, name='Not Cheddar', tagline='Anything but cheese.')
b4.save()  # Overrides the previous blog with ID=3!

See How Django knows to UPDATE vs. INSERT, below, for the reason thishappens.

Explicitly specifying auto-primary-key values is mostly useful for bulk-savingobjects, when you’re confident you won’t have primary-key collision.

If you’re using PostgreSQL, the sequence associated with the primary key mightneed to be updated; see Manually-specifying values of auto-incrementing primary keys.

What happens when you save?

When you save an object, Django performs the following steps:

• Emit a pre-save signal. The pre_savesignal is sent, allowing any functions listening for that signal to dosomething.

• Preprocess the data. Each field’spre_save() method is called to perform anyautomated data modification that’s needed. For example, the date/time fieldsoverride pre_save() to implementauto_now_add andauto_now.

• Prepare the data for the database. Each field’sget_db_prep_save() method is asked to provideits current value in a data type that can be written to the database.

Most fields don’t require data preparation. Simple data types, such asintegers and strings, are ‘ready to write’ as a Python object. However, morecomplex data types often require some modification.

For example, DateField fields use a Pythondatetime object to store data. Databases don’t store datetimeobjects, so the field value must be converted into an ISO-compliant datestring for insertion into the database.

• Insert the data into the database. The preprocessed, prepared data iscomposed into an SQL statement for insertion into the database.

• Emit a post-save signal. The post_savesignal is sent, allowing any functions listening for that signal to dosomething.

How Django knows to UPDATE vs. INSERT

You may have noticed Django database objects use the same save() methodfor creating and changing objects. Django abstracts the need to use INSERTor UPDATE SQL statements. Specifically, when you call save(), Djangofollows this algorithm:

• If the object’s primary key attribute is set to a value that evaluates toTrue (i.e., a value other than None or the empty string), Djangoexecutes an UPDATE.
• If the object’s primary key attribute is not set or if the UPDATEdidn’t update anything (e.g. if primary key is set to a value that doesn’texist in the database), Django executes an INSERT.The one gotcha here is that you should be careful not to specify a primary-keyvalue explicitly when saving new objects, if you cannot guarantee theprimary-key value is unused. For more on this nuance, see Explicitly specifyingauto-primary-key values above and Forcing an INSERT or UPDATE below.

In Django 1.5 and earlier, Django did a SELECT when the primary keyattribute was set. If the SELECT found a row, then Django did an UPDATE,otherwise it did an INSERT. The old algorithm results in one more query inthe UPDATE case. There are some rare cases where the database doesn’treport that a row was updated even if the database contains a row for theobject’s primary key value. An example is the PostgreSQL ON UPDATE triggerwhich returns NULL. In such cases it is possible to revert to the oldalgorithm by setting the select_on_saveoption to True.

Forcing an INSERT or UPDATE

In some rare circumstances, it’s necessary to be able to force thesave() method to perform an SQL INSERT and not fall back todoing an UPDATE. Or vice-versa: update, if possible, but not insert a newrow. In these cases you can pass the forceinsert=True orforce_update=True parameters to the save() method.Passing both parameters is an error: you cannot both insert _and update at thesame time!

It should be very rare that you’ll need to use these parameters. Django willalmost always do the right thing and trying to override that will lead toerrors that are difficult to track down. This feature is for advanced useonly.

Using update_fields will force an update similarly to force_update.

Updating attributes based on existing fields

Sometimes you’ll need to perform a simple arithmetic task on a field, suchas incrementing or decrementing the current value. The obvious way toachieve this is to do something like:

>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold += 1
>>> product.save()

If the old number_sold value retrieved from the database was 10, thenthe value of 11 will be written back to the database.

The process can be made robust, avoiding a race condition, as well as slightly faster by expressingthe update relative to the original field value, rather than as an explicitassignment of a new value. Django provides F expressions for performing this kind of relative update. UsingF expressions, the previous example is expressedas:

>>> from django.db.models import F
>>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
>>> product.number_sold = F('number_sold') + 1
>>> product.save()

For more details, see the documentation on F expressions and their use in update queries.

Specifying which fields to save

If save() is passed a list of field names in keyword argumentupdate_fields, only the fields named in that list will be updated.This may be desirable if you want to update just one or a few fields onan object. There will be a slight performance benefit from preventingall of the model fields from being updated in the database. For example:

product.name = 'Name changed again'
product.save(update_fields=['name'])

The update_fields argument can be any iterable containing strings. Anempty update_fields iterable will skip the save. A value of None willperform an update on all fields.

Specifying update_fields will force an update.

When saving a model fetched through deferred model loading(only() ordefer()) only the fields loadedfrom the DB will get updated. In effect there is an automaticupdate_fields in this case. If you assign or change any deferred fieldvalue, the field will be added to the updated fields.

Deleting objects

• Model.delete(using=DEFAULT_DB_ALIAS, keep_parents=False)
• Issues an SQL DELETE for the object. This only deletes the object in thedatabase; the Python instance will still exist and will still have data inits fields. This method returns the number of objects deleted and a dictionarywith the number of deletions per object type.

For more details, including how to delete objects in bulk, seeDeleting objects.

If you want customized deletion behavior, you can override the delete()method. See Overriding predefined model methods for more details.

Sometimes with multi-table inheritance you maywant to delete only a child model’s data. Specifying keep_parents=True willkeep the parent model’s data.

Pickling objects

When you pickle a model, its current state is pickled. When you unpickleit, it’ll contain the model instance at the moment it was pickled, rather thanthe data that’s currently in the database.

You can’t share pickles between versions

Pickles of models are only valid for the version of Django thatwas used to generate them. If you generate a pickle using Djangoversion N, there is no guarantee that pickle will be readable withDjango version N+1. Pickles should not be used as part of a long-termarchival strategy.

Since pickle compatibility errors can be difficult to diagnose, such assilently corrupted objects, a RuntimeWarning is raised when you try tounpickle a model in a Django version that is different than the one inwhich it was pickled.

Other model instance methods

A few object methods have special purposes.

str()

• Model.str()
• The str() method is called whenever you call str() on an object.Django uses str(obj) in a number of places. Most notably, to display anobject in the Django admin site and as the value inserted into a template whenit displays an object. Thus, you should always return a nice, human-readablerepresentation of the model from the str() method.

For example:

from django.db import models
 
class Person(models.Model):
    first_name = models.CharField(max_length=50)
    last_name = models.CharField(max_length=50)
 
    def __str__(self):
        return '%s %s' % (self.first_name, self.last_name)

eq()

• Model.eq()
• The equality method is defined such that instances with the same primarykey value and the same concrete class are considered equal, except thatinstances with a primary key value of None aren’t equal to anything exceptthemselves. For proxy models, concrete class is defined as the model’s firstnon-proxy parent; for all other models it’s simply the model’s class.

For example:

from django.db import models
 
class MyModel(models.Model):
    id = models.AutoField(primary_key=True)
 
class MyProxyModel(MyModel):
    class Meta:
        proxy = True
 
class MultitableInherited(MyModel):
    pass
 
# Primary keys compared
MyModel(id=1) == MyModel(id=1)
MyModel(id=1) != MyModel(id=2)
# Primary keys are None
MyModel(id=None) != MyModel(id=None)
# Same instance
instance = MyModel(id=None)
instance == instance
# Proxy model
MyModel(id=1) == MyProxyModel(id=1)
# Multi-table inheritance
MyModel(id=1) != MultitableInherited(id=1)

hash()

• Model.hash()
• The hash() method is based on the instance’s primary key value. Itis effectively hash(obj.pk). If the instance doesn’t have a primary keyvalue then a TypeError will be raised (otherwise the hash()method would return different values before and after the instance issaved, but changing the hash() value of an instance isforbidden in Python.

get_absolute_url()

• Model.get_absolute_url()
• Define a get_absolute_url() method to tell Django how to calculate thecanonical URL for an object. To callers, this method should appear to return astring that can be used to refer to the object over HTTP.

For example:

def get_absolute_url(self):
    return "/people/%i/" % self.id

While this code is correct and simple, it may not be the most portable way toto write this kind of method. The reverse() function isusually the best approach.

For example:

def get_absolute_url(self):
    from django.urls import reverse
    return reverse('people.views.details', args=[str(self.id)])

One place Django uses get_absolute_url() is in the admin app. If an objectdefines this method, the object-editing page will have a “View on site” linkthat will jump you directly to the object’s public view, as given byget_absolute_url().

Similarly, a couple of other bits of Django, such as the syndication feedframework, use get_absolute_url() when it isdefined. If it makes sense for your model’s instances to each have a uniqueURL, you should define get_absolute_url().

Warning

You should avoid building the URL from unvalidated user input, in order toreduce possibilities of link or redirect poisoning:

def get_absolute_url(self):
    return '/%s/' % self.name

If self.name is '/example.com' this returns '//example.com/'which, in turn, is a valid schema relative URL but not the expected'/%2Fexample.com/'.

It’s good practice to use get_absolute_url() in templates, instead ofhard-coding your objects’ URLs. For example, this template code is bad:

<!-- BAD template code. Avoid! -->
<a href="/people/{{ object.id }}/">{{ object.name }}</a>

This template code is much better:

<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>

The logic here is that if you change the URL structure of your objects, evenfor something small like correcting a spelling error, you don’t want to have totrack down every place that the URL might be created. Specify it once, inget_absolute_url() and have all your other code call that one place.

Note

The string you return from get_absolute_url() must contain onlyASCII characters (required by the URI specification, RFC 2396) and beURL-encoded, if necessary.

Code and templates calling get_absolute_url() should be able to use theresult directly without any further processing. You may wish to use thedjango.utils.encoding.iri_to_uri() function to help with this if youare using strings containing characters outside the ASCII range.

Extra instance methods

In addition to save(), delete(), a model objectmight have some of the following methods:

• Model.get_FOO_display()
• For every field that has choices set, theobject will have a get_FOO_display() method, where FOO is the name ofthe field. This method returns the “human-readable” value of the field.

For example:

from django.db import models
 
class Person(models.Model):
    SHIRT_SIZES = (
        ('S', 'Small'),
        ('M', 'Medium'),
        ('L', 'Large'),
    )
    name = models.CharField(max_length=60)
    shirt_size = models.CharField(max_length=2, choices=SHIRT_SIZES)

>>> p = Person(name="Fred Flintstone", shirt_size="L")
>>> p.save()
>>> p.shirt_size
'L'
>>> p.get_shirt_size_display()
'Large'

• Model.getnext_by_FOO(**kwargs_)
• Model.getprevious_by_FOO(**kwargs_)
• For every DateField andDateTimeField that does not have null=True, the object will have get_next_by_FOO() andget_previous_by_FOO() methods, where FOO is the name of the field. Thisreturns the next and previous object with respect to the date field, raisinga DoesNotExist exception when appropriate.

Both of these methods will perform their queries using the defaultmanager for the model. If you need to emulate filtering used by acustom manager, or want to perform one-off custom filtering, bothmethods also accept optional keyword arguments, which should be in theformat described in Field lookups.

Note that in the case of identical date values, these methods will use theprimary key as a tie-breaker. This guarantees that no records are skipped orduplicated. That also means you cannot use those methods on unsaved objects.

Other attributes

DoesNotExist

• exception Model.DoesNotExist
• This exception is raised by the ORM in a couple places, for example byQuerySet.get() when an objectis not found for the given query parameters.

Django provides a DoesNotExist exception as an attribute of each modelclass to identify the class of object that could not be found and to allowyou to catch a particular model class with try/except. The exception isa subclass of django.core.exceptions.ObjectDoesNotExist.