Django save model error

Note

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

1. 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")
   

2. 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.from_db(db, field_names, values)¶

The from_db() method can be used to customize model instance creation
when loading from the database.

The db argument contains the database alias for the database the model
is loaded from, field_names contains the names of all loaded fields, and
values contains the loaded values for each field in field_names. The
field_names are in the same order as the values. If all of the model’s
fields are present, then values are guaranteed to be in the order
__init__() expects them. That is, the instance can be created by
cls(*values). If any fields are deferred, they won’t appear in
field_names. In that case, assign a value of django.db.models.DEFERRED
to each of the missing fields.

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

Below is an example showing how to record the initial values of fields that
are 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, (value for value in values if value is not DEFERRED))
    )
    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 that
is done. In this case it would be possible to use a super() call in the
from_db() method.

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

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)

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)

Warning

Constraints containing JSONField may not raise
validation errors as key, index, and path transforms have many
database-specific caveats. This may be fully supported later.

You should always check that there are no log messages, in the
django.db.models logger, like “Got a database error calling check() on
…” to confirm it’s validated properly.

Changed in Django 4.1:

In older versions, constraints were not checked during the model
validation.

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

Changed in Django 4.1:

The validate_constraints argument was added.

Changed in Django 4.1:

An exclude value is now converted to a set rather than a list.

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()

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]

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.')})
        ...

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

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 that
don’t appear in a model form (a form may limit its fields using
Meta.fields or Meta.exclude). Doing so will raise a ValueError
because the validation error won’t be able to be associated with the
excluded field.

To work around this dilemma, instead override Model.clean_fields() as it receives the list of fields
that 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.'
                     ),
                })

Changed in Django 4.1:

In older versions, UniqueConstraints were
validated by validate_unique().

Auto-incrementing primary keys¶

If a model has an AutoField — an auto-incrementing
primary key — then that auto-incremented value will be calculated and saved as
an 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 call
save(), because that value is calculated by your database, not by Django.

For convenience, each model has an AutoField named
id by default unless you explicitly specify primary_key=True on a field
in your model. See the documentation for AutoField
for more details.

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

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

What happens when you save?¶

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

1. Emit a pre-save signal. The pre_save
   signal is sent, allowing any functions listening for that signal to do
   something.

2. Preprocess the data. Each field’s
   pre_save() method is called to perform any
   automated data modification that’s needed. For example, the date/time fields
   override pre_save() to implement
   auto_now_add and
   auto_now.

3. Prepare the data for the database. Each field’s
   get_db_prep_save() method is asked to provide
   its current value in a data type that can be written to the database.

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

   For example, DateField fields use a Python
   datetime object to store data. Databases don’t store datetime
   objects, so the field value must be converted into an ISO-compliant date
   string for insertion into the database.

4. Insert the data into the database. The preprocessed, prepared data is
   composed into an SQL statement for insertion into the database.

5. Emit a post-save signal. The post_save
   signal is sent, allowing any functions listening for that signal to do
   something.

How Django knows to UPDATE vs. INSERT¶

You may have noticed Django database objects use the same save() method
for creating and changing objects. Django abstracts the need to use INSERT
or UPDATE SQL statements. Specifically, when you call save() and the
object’s primary key attribute does not define a
default, Django follows this algorithm:

• If the object’s primary key attribute is set to a value that evaluates to
  True (i.e., a value other than None or the empty string), Django
  executes an UPDATE.
• If the object’s primary key attribute is not set or if the UPDATE
  didn’t update anything (e.g. if primary key is set to a value that doesn’t
  exist in the database), Django executes an INSERT.

If the object’s primary key attribute defines a
default then Django executes an UPDATE if
it is an existing model instance and primary key is set to a value that exists
in the database. Otherwise, Django executes an INSERT.

The one gotcha here is that you should be careful not to specify a primary-key
value explicitly when saving new objects, if you cannot guarantee the
primary-key value is unused. For more on this nuance, see Explicitly specifying
auto-primary-key values above and Forcing an INSERT or UPDATE below.

In Django 1.5 and earlier, Django did a SELECT when the primary key
attribute 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 in
the UPDATE case. There are some rare cases where the database doesn’t
report that a row was updated even if the database contains a row for the
object’s primary key value. An example is the PostgreSQL ON UPDATE trigger
which returns NULL. In such cases it is possible to revert to the old
algorithm by setting the select_on_save
option to True.

Updating attributes based on existing fields¶

Sometimes you’ll need to perform a simple arithmetic task on a field, such
as incrementing or decrementing the current value. One way of achieving this is
doing the arithmetic in Python 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, then
the 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 expressing
the update relative to the original field value, rather than as an explicit
assignment of a new value. Django provides F expressions for performing this kind of relative update. Using
F expressions, the previous example is expressed
as:

>>> 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 argument
update_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 on
an object. There will be a slight performance benefit from preventing
all 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. An
empty update_fields iterable will skip the save. A value of None will
perform an update on all fields.

Specifying update_fields will force an update.

When saving a model fetched through deferred model loading
(only() or
defer()) only the fields loaded
from the DB will get updated. In effect there is an automatic
update_fields in this case. If you assign or change any deferred field
value, the field will be added to the updated fields.

__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 an
object in the Django admin site and as the value inserted into a template when
it displays an object. Thus, you should always return a nice, human-readable
representation 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 primary
key value and the same concrete class are considered equal, except that
instances with a primary key value of None aren’t equal to anything except
themselves. For proxy models, concrete class is defined as the model’s first
non-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. It
is effectively hash(obj.pk). If the instance doesn’t have a primary key
value then a TypeError will be raised (otherwise the __hash__()
method would return different values before and after the instance is
saved, but changing the __hash__() value of an instance is
forbidden in Python.

get_absolute_url()¶

Model.get_absolute_url()¶

Define a get_absolute_url() method to tell Django how to calculate the
canonical URL for an object. To callers, this method should appear to return a
string 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 to
to write this kind of method. The reverse() function is
usually the best approach.

For example:

def get_absolute_url(self):
    from django.urls import reverse
    return reverse('people-detail', kwargs={'pk' : self.pk})

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

Similarly, a couple of other bits of Django, such as the syndication feed
framework, use get_absolute_url() when it is
defined. If it makes sense for your model’s instances to each have a unique
URL, you should define get_absolute_url().

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

It’s good practice to use get_absolute_url() in templates, instead of
hard-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, even
for something small like correcting a spelling error, you don’t want to have to
track down every place that the URL might be created. Specify it once, in
get_absolute_url() and have all your other code call that one place.

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'

Overriding extra instance methods

In most cases overriding or inheriting get_FOO_display(),
get_next_by_FOO(), and get_previous_by_FOO() should work as
expected. Since they are added by the metaclass however, it is not
practical to account for all possible inheritance structures. In more
complex cases you should override Field.contribute_to_class() to set
the methods you need.

_state¶

Model._state¶

The _state attribute refers to a ModelState object that tracks
the lifecycle of the model instance.

The ModelState object has two attributes: adding, a flag which is
True if the model has not been saved to the database yet, and db,
a string referring to the database alias the instance was loaded from or
saved to.

Newly instantiated instances have adding=True and db=None,
since they are yet to be saved. Instances fetched from a QuerySet
will have adding=False and db set to the alias of the associated
database.