This document describes the details of the Model API. It builds on the material presented in the model and database query guides, so you’ll probably want to read and understand those documents before reading this one.
Throughout this reference we’ll use the example weblog models presented in the database query guide.
To create a new instance of a model, just instantiate it like any other Python class:
The keyword arguments are simply the names of the fields you’ve defined on your model. Note that instantiating a model in no way touches your database; for that, you need to save().
To save an object back to the database, call save():
Of course, there are some subtleties; see the sections below.
The signature of the save() method has changed from earlier versions (force_insert and force_update have been added). If you are overriding these methods, be sure to use the correct signature.
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 b 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. See the documentation for AutoField for more details.
Regardless of whether you define a primary key field yourself, or let Django supply one for you, each model will have a property called pk. It behaves like a normal attribute on the model, but is actually an alias for whichever attribute is the primary key field for the model. You can read and set this value, just as you would for any other attribute, and it will update the correct field in the model.
If a model has an AutoField but you want to define a new object's ID explicitly when saving, just 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 an already-existing primary-key value! If you create a new object with an explicit primary-key value that already exists in the database, Django will assume you're changing the existing record rather than creating a new one.
Given the above 'Cheddar Talk' blog example, this example would override the previous 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 this happens.
Explicitly specifying auto-primary-key values is mostly useful for bulk-saving objects, when you're confident you won't have primary-key collision.
When you save an object, Django performs the following steps:
Emit a pre-save signal. The signal django.db.models.signals.pre_save is sent, allowing any functions listening for that signal to take some customized action.
Pre-process the data. Each field on the object is asked to perform any automated data modification that the field may need to perform.
Most fields do no pre-processing -- the field data is kept as-is. Pre-processing is only used on fields that have special behavior. For example, if your model has a DateField with auto_now=True, the pre-save phase will alter the data in the object to ensure that the date field contains the current date stamp. (Our documentation doesn't yet include a list of all the fields with this "special behavior.")
Prepare the data for the database. Each field is asked to provide its current value in a data type that can be written to the database.
Most fields require no 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, DateFields 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.
Insert the data into the database. The pre-processed, prepared data is then composed into an SQL statement for insertion into the database.
Emit a post-save signal. The signal django.db.models.signals.post_save is sent, allowing any functions listening for that signal to take some customized action.
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(), Django follows this algorithm:
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 some rare circumstances, it's necessary to be able to force the save() method to perform an SQL INSERT and not fall back to doing an UPDATE. Or vice-versa: update, if possible, but not insert a new row. In these cases you can pass the force_insert=True or force_update=True parameters to the save() method. Passing both parameters is an error, since you cannot both insert and update at the same time.
It should be very rare that you'll need to use these parameters. Django will almost always do the right thing and trying to override that will lead to errors that are difficult to track down. This feature is for advanced use only.
Sometimes you'll need to perform a simple arithmetic task on a field, such as incrementing or decrementing the current value. The obvious way to achieve 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, then the value of 11 will be written back to the database.
This can be optimized slightly by expressing the update relative to the original field value, rather than as an explicit assignment of a new value. Django provides F() expressions as a way of performing this kind of relative update. Using F() expressions, the previous example would be 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()
This approach doesn't use the initial value from the database. Instead, it makes the database do the update based on whatever value is current at the time that the save() is executed.
Once the object has been saved, you must reload the object in order to access the actual value that was applied to the updated field:
>>> product = Products.objects.get(pk=product.pk)
>>> print product.number_sold
42
For more details, see the documentation on F() expressions and their use in update queries.
Issues a SQL DELETE for the object. This only deletes the object in the database; the Python instance will still be around, and will still have data in its fields.
For more details, including how to delete objects in bulk, see Deleting objects.
A few object methods have special purposes.
__str__() is a Python "magic method" that defines what should be returned if you call str() on the object. Django uses str(obj) (or the related function, unicode(obj) -- see below) in a number of places, most notably as the value displayed to render 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 string for the object's __str__. Although this isn't required, it's strongly encouraged (see the description of __unicode__, below, before putting __str__ methods everywhere).
For example:
class Person(models.Model):
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
def __str__(self):
# Note use of django.utils.encoding.smart_str() here because
# first_name and last_name will be unicode strings.
return smart_str('%s %s' % (self.first_name, self.last_name))
The __unicode__() method is called whenever you call unicode() on an object. Since Django's database backends will return Unicode strings in your model's attributes, you would normally want to write a __unicode__() method for your model. The example in the previous section could be written more simply as:
class Person(models.Model):
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
def __unicode__(self):
return u'%s %s' % (self.first_name, self.last_name)
If you define a __unicode__() method on your model and not a __str__() method, Django will automatically provide you with a __str__() that calls __unicode__() and then converts the result correctly to a UTF-8 encoded string object. This is recommended development practice: define only __unicode__() and let Django take care of the conversion to string objects when required.
Define a get_absolute_url() method to tell Django how to calculate the URL for an object. For example:
def get_absolute_url(self):
return "/people/%i/" % self.id
Django uses this in its admin interface. If an object defines get_absolute_url(), the object-editing page will have a "View on site" link that will jump you directly to the object's public view, according to get_absolute_url().
Also, a couple of other bits of Django, such as the syndication feed framework, use get_absolute_url() as a convenience to reward people who've defined the method.
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:
<a href="/people/{{ object.id }}/">{{ object.name }}</a>
But this template code is good:
<a href="{{ object.get_absolute_url }}">{{ object.name }}</a>
Note
The string you return from get_absolute_url() must contain only ASCII characters (required by the URI spec, RFC 2396) that have been URL-encoded, if necessary. Code and templates using get_absolute_url() should be able to use the result directly without needing to do any further processing. You may wish to use the django.utils.encoding.iri_to_uri() function to help with this if you are using unicode strings a lot.
The problem with the way we wrote get_absolute_url() above is that it slightly violates the DRY principle: the URL for this object is defined both in the URLconf file and in the model.
You can further decouple your models from the URLconf using the permalink decorator:
This decorator is passed the view function, a list of positional parameters and (optionally) a dictionary of named parameters. Django then works out the correct full URL path using the URLconf, substituting the parameters you have given into the URL. For example, if your URLconf contained a line such as:
(r'^people/(\d+)/$', 'people.views.details'),
...your model could have a get_absolute_url method that looked like this:
from django.db import models
@models.permalink
def get_absolute_url(self):
return ('people.views.details', [str(self.id)])
Similarly, if you had a URLconf entry that looked like:
(r'/archive/(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<day>\d{1,2})/$', archive_view)
...you could reference this using permalink() as follows:
@models.permalink
def get_absolute_url(self):
return ('archive_view', (), {
'year': self.created.year,
'month': self.created.month,
'day': self.created.day})
Notice that we specify an empty sequence for the second parameter in this case, because we only want to pass keyword parameters, not positional ones.
In this way, you're tying the model's absolute URL to the view that is used to display it, without repeating the URL information anywhere. You can still use the get_absolute_url method in templates, as before.
In some cases, such as the use of generic views or the re-use of custom views for multiple models, specifying the view function may confuse the reverse URL matcher (because multiple patterns point to the same view).
For that problem, Django has named URL patterns. Using a named URL pattern, it's possible to give a name to a pattern, and then reference the name rather than the view function. A named URL pattern is defined by replacing the pattern tuple by a call to the url function):
from django.conf.urls.defaults import *
url(r'^people/(\d+)/$',
'django.views.generic.list_detail.object_detail',
name='people_view'),
...and then using that name to perform the reverse URL resolution instead of the view name:
from django.db.models import permalink
def get_absolute_url(self):
return ('people_view', [str(self.id)])
get_absolute_url = permalink(get_absolute_url)
More details on named URL patterns are in the URL dispatch documentation.
In addition to save(), delete(), a model object might get any or all of the following methods:
For every field that has choices set, the object will have a get_FOO_display() method, where FOO is the name of the field. This method returns the "human-readable" value of the field. For example, in the following model:
GENDER_CHOICES = (
('M', 'Male'),
('F', 'Female'),
)
class Person(models.Model):
name = models.CharField(max_length=20)
gender = models.CharField(max_length=1, choices=GENDER_CHOICES)
...each Person instance will have a get_gender_display() method. Example:
>>> p = Person(name='John', gender='M')
>>> p.save()
>>> p.gender
'M'
>>> p.get_gender_display()
'Male'
For every DateField and DateTimeField that does not have null=True, the object will have get_next_by_FOO() and get_previous_by_FOO() methods, where FOO is the name of the field. This returns the next and previous object with respect to the date field, raising the appropriate DoesNotExist exception when appropriate.
Both methods accept optional keyword arguments, which should be in the format described in Field lookups.
Note that in the case of identical date values, these methods will use the ID as a fallback check. This guarantees that no records are skipped or duplicated.
Sep 20, 2009