Django中的Model定义和各Model之间的一对一、多对一，多对多关系以及级联查询的问题

参考官方网站：https://docs.djangoproject.com/en/dev/topics/db/queries/

Making queries¶

Once you’ve created your data models, Django automatically gives you a database-abstraction API that lets you create, retrieve, update and delete objects. This document explains how to use this API. Refer to thedata model reference for full details of all the various model lookup options.

Throughout this guide (and in the reference), we’ll refer to the following models, which comprise a Weblog application:

class Blog(models.Model):
    name = models.CharField(max_length=100)
    tagline = models.TextField()

    def __unicode__(self):
        return self.name

class Author(models.Model):
    name = models.CharField(max_length=50)
    email = models.EmailField()

    def __unicode__(self):
        return self.name

class Entry(models.Model):
    blog = models.ForeignKey(Blog)
    headline = models.CharField(max_length=255)
    body_text = models.TextField()
    pub_date = models.DateTimeField()
    mod_date = models.DateTimeField()
    authors = models.ManyToManyField(Author)
    n_comments = models.IntegerField()
    n_pingbacks = models.IntegerField()
    rating = models.IntegerField()

    def __unicode__(self):
        return self.headline

 

Creating objects ¶

To represent database-table data in Python objects, Django uses an intuitive system: A model class represents a database table, and an instance of that class represents a particular record in the database table.

To create an object, instantiate it using keyword arguments to the model class, then callsave() to save it to the database.

You import the model class from wherever it lives on the Python path, as you may expect. (We point this out here because previous Django versions required funky model importing.)

Assuming models live in a file mysite/blog/models.py, here's an example:

>>> from blog.models import Blog
>>> b = Blog(name='Beatles Blog', tagline='All the latest Beatles news.')
>>> b.save()

This performs an INSERT SQL statement behind the scenes. Django doesn't hit the database until you explicitly call save() .

The save() method has no return value.

See also

save() takes a number of advanced options not described here. See the documentation forsave() for complete details.

To create and save an object in a single step, use thecreate() method.

Saving changes to objects¶

To save changes to an object that's already in the database, usesave().

Given a Blog instanceb5 that has already been saved to the database, this example changes its name and updates its record in the database:

>> b5.name = 'New name'
>> b5.save()

This performs an UPDATE SQL statement behind the scenes. Django doesn't hit the database until you explicitly call save() .

Saving ForeignKey andManyToManyField fields¶

Updating a ForeignKey field works exactly the same way as saving a normal field -- simply assign an object of the right type to the field in question. This example updates theblog attribute of anEntry instanceentry:

>>> from blog.models import Entry
>>> entry = Entry.objects.get(pk=1)
>>> cheese_blog = Blog.objects.get(name="Cheddar Talk")
>>> entry.blog = cheese_blog
>>> entry.save()

Updating a ManyToManyField works a little differently -- use the add() method on the field to add a record to the relation. This example adds theAuthor instancejoe to theentry object:

>>> from blog.models import Author
>>> joe = Author.objects.create(name="Joe")
>>> entry.authors.add(joe)

To add multiple records to a ManyToManyField in one go, include multiple arguments in the call to add() , like this:

>>> john = Author.objects.create(name="John")
>>> paul = Author.objects.create(name="Paul")
>>> george = Author.objects.create(name="George")
>>> ringo = Author.objects.create(name="Ringo")
>>> entry.authors.add(john, paul, george, ringo)

Django will complain if you try to assign or add an object of the wrong type.

Retrieving objects¶

To retrieve objects from your database, construct aQuerySet via aManager on your model class.

A QuerySet represents a collection of objects from your database. It can have zero, one or manyfilters -- criteria that narrow down the collection based on given parameters. In SQL terms, aQuerySet equates to aSELECT statement, and a filter is a limiting clause such asWHERE orLIMIT.

You get a QuerySet by using your model'sManager. Each model has at least oneManager, and it's calledobjects by default. Access it directly via the model class, like so:

>>> Blog.objects

>>> b = Blog(name='Foo', tagline='Bar')
>>> b.objects
Traceback:
    ...
AttributeError: "Manager isn't accessible via Blog instances."

Note

Managers are accessible only via model classes, rather than from model instances, to enforce a separation between "table-level" operations and "record-level" operations.

The Manager is the main source ofQuerySets for a model. It acts as a "root"QuerySet that describes all objects in the model's database table. For example,Blog.objects is the initialQuerySet that contains allBlog objects in the database.

Retrieving all objects¶

The simplest way to retrieve objects from a table is to get all of them. To do this, use theall() method on aManager:

>>> all_entries = Entry.objects.all()

 

The all() method returns a QuerySet of all the objects in the database.

(If Entry.objects is aQuerySet, why can't we just doEntry.objects? That's becauseEntry.objects, the rootQuerySet, is a special case that cannot be evaluated. Theall() method returns aQuerySet thatcan be evaluated.)

Retrieving specific objects with filters¶

The root QuerySet provided by theManager describes all objects in the database table. Usually, though, you'll need to select only a subset of the complete set of objects.

To create such a subset, you refine the initial QuerySet, adding filter conditions. The two most common ways to refine aQuerySet are:

filter(**kwargs)

Returns a new QuerySet containing objects that match the given lookup parameters.

exclude(**kwargs)

Returns a new QuerySet containing objects that donot match the given lookup parameters.

The lookup parameters (**kwargs in the above function definitions) should be in the format described inField lookups below.

For example, to get a QuerySet of blog entries from the year 2006, usefilter() like so:

Entry.objects.filter(pub_date__year=2006)

We don't have to add an all() --Entry.objects.all().filter(...). That would still work, but you only need all() when you want all objects from the root QuerySet .

Chaining filters¶

The result of refining a QuerySet is itself aQuerySet, so it's possible to chain refinements together. For example:

>>> Entry.objects.filter(
...     headline__startswith='What'
... ).exclude(
...     pub_date__gte=datetime.now()
... ).filter(
...     pub_date__gte=datetime(2005, 1, 1)
... )

 

This takes the initial QuerySet of all entries in the database, adds a filter, then an exclusion, then another filter. The final result is a QuerySet containing all entries with a headline that starts with "What", that were published between January 1, 2005, and the current day.

Filtered QuerySets are unique¶

Each time you refine a QuerySet, you get a brand-newQuerySet that is in no way bound to the previousQuerySet. Each refinement creates a separate and distinctQuerySet that can be stored, used and reused.

Example:

>> q1 = Entry.objects.filter(headline__startswith="What")
>> q2 = q1.exclude(pub_date__gte=datetime.now())
>> q3 = q1.filter(pub_date__gte=datetime.now())

 

These three QuerySets are separate. The first is a base QuerySet containing all entries that contain a headline starting with "What". The second is a subset of the first, with an additional criteria that excludes records whosepub_date is greater than now. The third is a subset of the first, with an additional criteria that selects only the records whosepub_date is greater than now. The initial QuerySet (q1) is unaffected by the refinement process.

QuerySets are lazy¶

QuerySets are lazy -- the act of creating aQuerySet doesn't involve any database activity. You can stack filters together all day long, and Django won't actually run the query until theQuerySet isevaluated. Take a look at this example:

>>> q = Entry.objects.filter(headline__startswith="What")
>>> q = q.filter(pub_date__lte=datetime.now())
>>> q = q.exclude(body_text__icontains="food")
>>> print(q)

 

Though this looks like three database hits, in fact it hits the database only once, at the last line (print(q)). In general, the results of a QuerySet aren't fetched from the database until you "ask" for them. When you do, the QuerySet isevaluated by accessing the database. For more details on exactly when evaluation takes place, see When QuerySets are evaluated .

Retrieving a single object with get¶

filter() will always give you a QuerySet, even if only a single object matches the query - in this case, it will be aQuerySet containing a single element.

If you know there is only one object that matches your query, you can use theget() method on aManager which returns the object directly:

>>> one_entry = Entry.objects.get(pk=1)

You can use any query expression with get() , just like with filter() - again, see Field lookups below.

Note that there is a difference between using get(), and usingfilter() with a slice of[0]. If there are no results that match the query,get() will raise aDoesNotExist exception. This exception is an attribute of the model class that the query is being performed on - so in the code above, if there is noEntry object with a primary key of 1, Django will raiseEntry.DoesNotExist.

Similarly, Django will complain if more than one item matches theget() query. In this case, it will raiseMultipleObjectsReturned, which again is an attribute of the model class itself.

Other QuerySet methods¶

Most of the time you'll use all(),get(),filter() andexclude() when you need to look up objects from the database. However, that's far from all there is; see theQuerySet API Reference for a complete list of all the variousQuerySet methods.

Limiting QuerySets¶

Use a subset of Python's array-slicing syntax to limit yourQuerySet to a certain number of results. This is the equivalent of SQL'sLIMIT andOFFSET clauses.

For example, this returns the first 5 objects (LIMIT5):

>>> Entry.objects.all()[:5]

This returns the sixth through tenth objects (OFFSET5LIMIT5):

>>> Entry.objects.all()[5:10]

Negative indexing (i.e. Entry.objects.all()[-1]) is not supported.

Generally, slicing a QuerySet returns a newQuerySet -- it doesn't evaluate the query. An exception is if you use the "step" parameter of Python slice syntax. For example, this would actually execute the query in order to return a list of everysecond object of the first 10:

>>> Entry.objects.all()[:10:2]

To retrieve a single object rather than a list (e.g.SELECTfooFROMbarLIMIT1), use a simple index instead of a slice. For example, this returns the firstEntry in the database, after ordering entries alphabetically by headline:

>>> Entry.objects.order_by('headline')[0]

This is roughly equivalent to:

>>> Entry.objects.order_by('headline')[0:1].get()

Note, however, that the first of these will raiseIndexError while the second will raiseDoesNotExist if no objects match the given criteria. See get() for more details.

Field lookups¶

Field lookups are how you specify the meat of an SQLWHERE clause. They're specified as keyword arguments to theQuerySet methodsfilter(),exclude() andget().

Basic lookups keyword arguments take the form field__lookuptype=value. (That's a double-underscore). For example:

>>> Entry.objects.filter(pub_date__lte='2006-01-01')

translates (roughly) into the following SQL:

SELECT * FROM blog_entry WHERE pub_date <= '2006-01-01';

How this is possible

Python has the ability to define functions that accept arbitrary name-value arguments whose names and values are evaluated at runtime. For more information, seeKeyword Arguments in the official Python tutorial.

Changed in Django 1.4: The field specified in a lookup has to be the name of a model field. There's one exception though, in case of a ForeignKey you can specify the field name suffixed with_id. In this case, the value parameter is expected to contain the raw value of the foreign model's primary key. For example::

>>> Entry.objects.filter(blog_id__exact=4)

If you pass an invalid keyword argument, a lookup function will raiseTypeError.

The database API supports about two dozen lookup types; a complete reference can be found in thefield lookup reference. To give you a taste of what's available, here's some of the more common lookups you'll probably use:

exact

An "exact" match. For example:

 

>>> Entry.objects.get(headline__exact="Man bites dog")

Would generate SQL along these lines:

SELECT ... WHERE headline = 'Man bites dog';

If you don't provide a lookup type -- that is, if your keyword argument doesn't contain a double underscore -- the lookup type is assumed to beexact.

For example, the following two statements are equivalent:

 

>>> Blog.objects.get(id__exact=14)  # Explicit form
>>> Blog.objects.get(id=14)         # __exact is implied

 

This is for convenience, becauseexact lookups are the common case.

iexact

A case-insensitive match. So, the query:

 

>>> Blog.objects.get(name__iexact="beatles blog")

 

Would match a Blog titled "Beatles Blog", "beatles blog", or even "BeAtlES blOG".

contains

Case-sensitive containment test. For example:

 

Entry.objects.get(headline__contains='Lennon')

 

Roughly translates to this SQL:

SELECT ... WHERE headline LIKE '%Lennon%';

Note this will match the headline'TodayLennonhonored' but not'todaylennonhonored'.

There's also a case-insensitive version,icontains.

startswith , endswith

Starts-with and ends-with search, respectively. There are also case-insensitive versions called istartswith and iendswith .

Again, this only scratches the surface. A complete reference can be found in thefield lookup reference.

Lookups that span relationships¶

Django offers a powerful and intuitive way to "follow" relationships in lookups, taking care of the SQLJOINs for you automatically, behind the scenes. To span a relationship, just use the field name of related fields across models, separated by double underscores, until you get to the field you want.

This example retrieves all Entry objects with aBlog whosename is'BeatlesBlog':

>>> Entry.objects.filter(blog__name__exact='Beatles Blog')

 

This spanning can be as deep as you'd like.

It works backwards, too. To refer to a "reverse" relationship, just use the lowercase name of the model.

This example retrieves all Blog objects which have at least oneEntry whoseheadline contains'Lennon':

>>> Blog.objects.filter(entry__headline__contains='Lennon')

 

If you are filtering across multiple relationships and one of the intermediate models doesn't have a value that meets the filter condition, Django will treat it as if there is an empty (all values areNULL), but valid, object there. All this means is that no error will be raised. For example, in this filter:

Blog.objects.filter(entry__authors__name='Lennon')

(if there was a related Author model), if there was noauthor associated with an entry, it would be treated as if there was also noname attached, rather than raising an error because of the missingauthor. Usually this is exactly what you want to have happen. The only case where it might be confusing is if you are using isnull . Thus:

Blog.objects.filter(entry__authors__name__isnull=True)

will return Blog objects that have an emptyname on theauthor and also those which have an emptyauthor on theentry. If you don't want those latter objects, you could write:

Blog.objects.filter(entry__authors__isnull=False,
        entry__authors__name__isnull=True)

Spanning multi-valued relationships ¶

When you are filtering an object based on a ManyToManyField or a reverseForeignKey, there are two different sorts of filter you may be interested in. Consider theBlog/Entry relationship (Blog toEntry is a one-to-many relation). We might be interested in finding blogs that have an entry which has both"Lennon" in the headline and was published in 2008. Or we might want to find blogs that have an entry with"Lennon" in the headline as well as an entry that was published in 2008. Since there are multiple entries associated with a singleBlog, both of these queries are possible and make sense in some situations.

The same type of situation arises with a ManyToManyField. For example, if anEntry has aManyToManyField calledtags, we might want to find entries linked to tags called"music" and"bands" or we might want an entry that contains a tag with a name of"music" and a status of"public".

To handle both of these situations, Django has a consistent way of processingfi

Blog.objects.filter(entry__headline__contains='Lennon').filter(
        entry__pub_date__year=2008)

set of objects, but for multi-valued relations, they apply to any object linked to the primary model, not necessarily those objects that were selected by an earlierfilter() call.

That may sound a bit confusing, so hopefully an example will clarify. To select all blogs that contain entries with both"Lennon" in the headline and that were published in 2008 (the same entry satisfying both conditions), we would write:

Blog.objects.filter(entry__headline__contains='Lennon',
        entry__pub_date__year=2008)

To select all blogs that contain an entry with"Lennon" in the headlineas well as an entry that was published in 2008, we would write:

Blog.objects.filter(entry__headline__contains='Lennon').filter(
        entry__pub_date__year=2008)

 

In this second example, the first filter restricted the queryset to all those blogs linked to that particular type of entry. The second filter restricted the set of blogsfurther to those that are also linked to the second type of entry. The entries select by the second filter may or may not be the same as the entries in the first filter. We are filtering theBlog items with each filter statement, not theEntry items.

All of this behavior also applies to exclude(): all the conditions in a singleexclude() statement apply to a single instance (if those conditions are talking about the same multi-valued relation). Conditions in subsequentfilter() orexclude() calls that refer to the same relation may end up filtering on different linked objects.

Filters can reference fields on the model¶

In the examples given so far, we have constructed filters that compare the value of a model field with a constant. But what if you want to compare the value of a model field with another field on the same model?

Django provides the F() expressions to allow such comparisons. Instances of F() act as a reference to a model field within a query. These references can then be used in query filters to compare the values of two different fields on the same model instance.

For example, to find a list of all blog entries that have had more comments than pingbacks, we construct anF() object to reference the pingback count, and use thatF() object in the query:

>>> from django.db.models import F
>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks'))

Django supports the use of addition, subtraction, multiplication, division and modulo arithmetic withF() objects, both with constants and with otherF() objects. To find all the blog entries with more thantwice as many comments as pingbacks, we modify the query:

>>> Entry.objects.filter(n_comments__gt=F('n_pingbacks') * 2)

To find all the entries where the rating of the entry is less than the sum of the pingback count and comment count, we would issue the query:

>>> Entry.objects.filter(rating__lt=F('n_comments') + F('n_pingbacks'))

You can also use the double underscore notation to span relationships in anF() object. AnF() object with a double underscore will introduce any joins needed to access the related object. For example, to retrieve all the entries where the author's name is the same as the blog name, we could issue the query:

>>> Entry.objects.filter(authors__name=F('blog__name'))

New in Django 1.3: Please see the release notes

For date and date/time fields, you can add or subtract atimedelta object. The following would return all entries that were modified more than 3 days after they were published:

>>> from datetime import timedelta
>>> Entry.objects.filter(mod_date__gt=F('pub_date') + timedelta(days=3))

 

The pk lookup shortcut ¶

For convenience, Django provides a pk lookup shortcut, which stands for "primary key".

In the example Blog model, the primary key is theid field, so these three statements are equivalent:

>>> Blog.objects.get(id__exact=14) # Explicit form
>>> Blog.objects.get(id=14) # __exact is implied
>>> Blog.objects.get(pk=14) # pk implies id__exact

 

The use of pk isn't limited to__exact queries -- any query term can be combined withpk to perform a query on the primary key of a model:

# Get blogs entries with id 1, 4 and 7
>>> Blog.objects.filter(pk__in=[1,4,7])

# Get all blog entries with id > 14
>>> Blog.objects.filter(pk__gt=14)

pk lookups also work across joins. For example, these three statements are equivalent:

>>> Entry.objects.filter(blog__id__exact=3) # Explicit form
>>> Entry.objects.filter(blog__id=3)        # __exact is implied
>>> Entry.objects.filter(blog__pk=3)        # __pk implies __id__exact

Escaping percent signs and underscores in LIKE statements ¶

The field lookups that equate to LIKE SQL statements (iexact,contains,icontains,startswith,istartswith,endswith andiendswith) will automatically escape the two special characters used inLIKE statements -- the percent sign and the underscore. (In aLIKE statement, the percent sign signifies a multiple-character wildcard and the underscore signifies a single-character wildcard.)

This means things should work intuitively, so the abstraction doesn't leak. For example, to retrieve all the entries that contain a percent sign, just use the percent sign as any other character:

>>> Entry.objects.filter(headline__contains='%')

Django takes care of the quoting for you; the resulting SQL will look something like this:

SELECT ... WHERE headline LIKE '%\%%';

Same goes for underscores. Both percentage signs and underscores are handled for you transparently.

Caching and QuerySets¶

Each QuerySet contains a cache, to minimize database access. It's important to understand how it works, in order to write the most efficient code.

In a newly created QuerySet, the cache is empty. The first time aQuerySet is evaluated -- and, hence, a database query happens -- Django saves the query results in theQuerySet's cache and returns the results that have been explicitly requested (e.g., the next element, if theQuerySet is being iterated over). Subsequent evaluations of theQuerySet reuse the cached results.

Keep this caching behavior in mind, because it may bite you if you don't use yourQuerySets correctly. For example, the following will create twoQuerySets, evaluate them, and throw them away:

>>> print([e.headline for e in Entry.objects.all()])
>>> print([e.pub_date for e in Entry.objects.all()])

 

That means the same database query will be executed twice, effectively doubling your database load. Also, there's a possibility the two lists may not include the same database records, because anEntry may have been added or deleted in the split second between the two requests.

To avoid this problem, simply save the QuerySet and reuse it:

>>> queryset = Entry.objects.all()
>>> print([p.headline for p in queryset]) # Evaluate the query set.
>>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation.

 

Complex lookups with Q objects ¶

Keyword argument queries -- in filter(), etc. -- are "AND"ed together. If you need to execute more complex queries (for example, queries withOR statements), you can useQ objects.

A Q object (django.db.models.Q) is an object used to encapsulate a collection of keyword arguments. These keyword arguments are specified as in "Field lookups" above.

For example, this Q object encapsulates a singleLIKE query:

from django.db.models import Q
Q(question__startswith='What')

 

Q objects can be combined using the& and| operators. When an operator is used on twoQ objects, it yields a newQ object.

For example, this statement yields a single Q object that represents the "OR" of two"question__startswith" queries:

Q(question__startswith='Who') | Q(question__startswith='What')

 

This is equivalent to the following SQLWHERE clause:

WHERE question LIKE 'Who%' OR question LIKE 'What%'

You can compose statements of arbitrary complexity by combiningQ objects with the& and| operators and use parenthetical grouping. Also,Q objects can be negated using the~ operator, allowing for combined lookups that combine both a normal query and a negated (NOT) query:

Q(question__startswith='Who') | ~Q(pub_date__year=2005)

Each lookup function that takes keyword-arguments (e.g.filter(),exclude(),get()) can also be passed one or moreQ objects as positional (not-named) arguments. If you provide multipleQ object arguments to a lookup function, the arguments will be "AND"ed together. For example:

Poll.objects.get(
    Q(question__startswith='Who'),
    Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6))
)

 

... roughly translates into the SQL:

SELECT * from polls WHERE question LIKE 'Who%'
    AND (pub_date = '2005-05-02' OR pub_date = '2005-05-06')

Lookup functions can mix the use ofQ objects and keyword arguments. All arguments provided to a lookup function (be they keyword arguments orQ objects) are "AND"ed together. However, if aQ object is provided, it must precede the definition of any keyword arguments. For example:

Poll.objects.get(
    Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)),
    question__startswith='Who')

... would be a valid query, equivalent to the previous example; but:

# INVALID QUERY
Poll.objects.get(
    question__startswith='Who',
    Q(pub_date=date(2005, 5, 2)) | Q(pub_date=date(2005, 5, 6)))

... would not be valid.

See also

The OR lookups examples in the Django unit tests show some possible uses of Q.

Comparing objects¶

To compare two model instances, just use the standard Python comparison operator, the double equals sign:==. Behind the scenes, that compares the primary key values of two models.

Using the Entry example above, the following two statements are equivalent:

>>> some_entry == other_entry
>>> some_entry.id == other_entry.id

 

If a model's primary key isn't calledid, no problem. Comparisons will always use the primary key, whatever it's called. For example, if a model's primary key field is calledname, these two statements are equivalent:

>>> some_obj == other_obj
>>> some_obj.name == other_obj.name

Deleting objects ¶

The delete method, conveniently, is named delete(). This method immediately deletes the object and has no return value. Example:

e.delete()

 

You can also delete objects in bulk. Every QuerySet has a delete() method, which deletes all members of that QuerySet .

For example, this deletes all Entry objects with apub_date year of 2005:

Entry.objects.filter(pub_date__year=2005).delete()

 

Keep in mind that this will, whenever possible, be executed purely in SQL, and so thedelete() methods of individual object instances will not necessarily be called during the process. If you've provided a customdelete() method on a model class and want to ensure that it is called, you will need to "manually" delete instances of that model (e.g., by iterating over a QuerySet and callingdelete() on each object individually) rather than using the bulk delete() method of a QuerySet .

When Django deletes an object, by default it emulates the behavior of the SQL constraintONDELETECASCADE -- in other words, any objects which had foreign keys pointing at the object to be deleted will be deleted along with it. For example:

b = Blog.objects.get(pk=1)
# This will delete the Blog and all of its Entry objects.
b.delete()

 

New in Django 1.3: This cascade behavior is customizable via the on_delete argument to the ForeignKey .

Note that delete() is the onlyQuerySet method that is not exposed on aManager itself. This is a safety mechanism to prevent you from accidentally requestingEntry.objects.delete(), and deletingall the entries. If youdo want to delete all the objects, then you have to explicitly request a complete query set:

Entry.objects.all().delete()

 

Copying model instances ¶

Although there is no built-in method for copying model instances, it is possible to easily create new instance with all fields' values copied. In the simplest case, you can just setpk toNone. Using our blog example:

blog = Blog(name='My blog', tagline='Blogging is easy')
blog.save() # post.pk == 1

blog.pk = None
blog.save() # post.pk == 2

 

Things get more complicated if you use inheritance. Consider a subclass ofBlog:

class ThemeBlog(Blog):
    theme = models.CharField(max_length=200)

django_blog = ThemeBlog(name='Django', tagline='Django is easy', theme = 'python')
django_blog.save() # django_blog.pk == 3

Due to how inheritance works, you have to set bothpk andid to None:

django_blog.pk = None
django_blog.id = None
django_blog.save() # django_blog.pk == 4

This process does not copy related objects. If you want to copy relations, you have to write a little bit more code. In our example,Entry has a many to many field toAuthor:

entry = Entry.objects.all()[0] # some previous entry
old_authors = entry.authors.all()
entry.pk = None
entry.save()
entry.authors = old_authors # saves new many2many relations

Updating multiple objects at once ¶

Sometimes you want to set a field to a particular value for all the objects in aQuerySet. You can do this with theupdate() method. For example:

# Update all the headlines with pub_date in 2007.
Entry.objects.filter(pub_date__year=2007).update(headline='Everything is the same')

 

You can only set non-relation fields and ForeignKey fields using this method. To update a non-relation field, provide the new value as a constant. To update ForeignKey fields, set the new value to be the new model instance you want to point to. For example:

>>> b = Blog.objects.get(pk=1)

# Change every Entry so that it belongs to this Blog.
>>> Entry.objects.all().update(blog=b)

The update() method is applied instantly and returns the number of rows affected by the query. The only restriction on the QuerySet that is updated is that it can only access one database table, the model's main table. You can filter based on related fields, but you can only update columns in the model's main table. Example:

>>> b = Blog.objects.get(pk=1)

# Update all the headlines belonging to this Blog.
>>> Entry.objects.select_related().filter(blog=b).update(headline='Everything is the same')

Be aware that the update() method is converted directly to an SQL statement. It is a bulk operation for direct updates. It doesn't run any save() methods on your models, or emit thepre_save orpost_save signals (which are a consequence of calling save() ). If you want to save every item in a QuerySet and make sure that the save() method is called on each instance, you don't need any special function to handle that. Just loop over them and call save() :

for item in my_queryset:
    item.save()

Calls to update can also use F() objects to update one field based on the value of another field in the model. This is especially useful for incrementing counters based upon their current value. For example, to increment the pingback count for every entry in the blog:

>>> Entry.objects.all().update(n_pingbacks=F('n_pingbacks') + 1)

However, unlike F() objects in filter and exclude clauses, you can't introduce joins when you useF() objects in an update -- you can only reference fields local to the model being updated. If you attempt to introduce a join with anF() object, aFieldError will be raised:

# THIS WILL RAISE A FieldError
>>> Entry.objects.update(headline=F('blog__name'))

Related objects ¶

When you define a relationship in a model (i.e., aForeignKey,OneToOneField, orManyToManyField), instances of that model will have a convenient API to access the related object(s).

Using the models at the top of this page, for example, anEntry objecte can get its associatedBlog object by accessing theblog attribute:e.blog.

(Behind the scenes, this functionality is implemented by Pythondescriptors. This shouldn't really matter to you, but we point it out here for the curious.)

Django also creates API accessors for the "other" side of the relationship -- the link from the related model to the model that defines the relationship. For example, aBlog objectb has access to a list of all relatedEntry objects via theentry_set attribute:b.entry_set.all().

All examples in this section use the sample Blog,Author andEntry models defined at the top of this page.

One-to-many relationships¶

Forward¶

If a model has a ForeignKey, instances of that model will have access to the related (foreign) object via a simple attribute of the model.

Example:

>>> e = Entry.objects.get(id=2)
>>> e.blog # Returns the related Blog object.

 

You can get and set via a foreign-key attribute. As you may expect, changes to the foreign key aren't saved to the database until you call save() . Example:

>>> e = Entry.objects.get(id=2)
>>> e.blog = some_blog
>>> e.save()

If a ForeignKey field hasnull=True set (i.e., it allowsNULL values), you can assignNone to it. Example:

>>> e = Entry.objects.get(id=2)
>>> e.blog = None
>>> e.save() # "UPDATE blog_entry SET blog_id = NULL ...;"

Forward access to one-to-many relationships is cached the first time the related object is accessed. Subsequent accesses to the foreign key on the same object instance are cached. Example:

>>> e = Entry.objects.get(id=2)
>>> print(e.blog)  # Hits the database to retrieve the associated Blog.
>>> print(e.blog)  # Doesn't hit the database; uses cached version.

Note that the select_related() QuerySet method recursively prepopulates the cache of all one-to-many relationships ahead of time. Example:

>>> e = Entry.objects.select_related().get(id=2)
>>> print(e.blog)  # Doesn't hit the database; uses cached version.
>>> print(e.blog)  # Doesn't hit the database; uses cached version.

Following relationships "backward" ¶

If a model has a ForeignKey, instances of the foreign-key model will have access to aManager that returns all instances of the first model. By default, thisManager is namedFOO_set, whereFOO is the source model name, lowercased. ThisManager returnsQuerySets, which can be filtered and manipulated as described in the "Retrieving objects" section above.

Example:

>>> b = Blog.objects.get(id=1)
>>> b.entry_set.all() # Returns all Entry objects related to Blog.

# b.entry_set is a Manager that returns QuerySets.
>>> b.entry_set.filter(headline__contains='Lennon')
>>> b.entry_set.count()

 

You can override the FOO_set name by setting therelated_name parameter in theForeignKey() definition. For example, if theEntry model was altered toblog=ForeignKey(Blog,related_name='entries'), the above example code would look like this:

>>> b = Blog.objects.get(id=1)
>>> b.entries.all() # Returns all Entry objects related to Blog.

# b.entries is a Manager that returns QuerySets.
>>> b.entries.filter(headline__contains='Lennon')
>>> b.entries.count()

You cannot access a reverse ForeignKey Manager from the class; it must be accessed from an instance:

>>> Blog.entry_set
Traceback:
    ...
AttributeError: "Manager must be accessed via instance".

In addition to the QuerySet methods defined in "Retrieving objects" above, the ForeignKey Manager has additional methods used to handle the set of related objects. A synopsis of each is below, and complete details can be found in the related objects reference .

add(obj1,obj2,...)

Adds the specified model objects to the related object set.

create(**kwargs)

Creates a new object, saves it and puts it in the related object set. Returns the newly created object.

remove(obj1,obj2,...)

Removes the specified model objects from the related object set.

clear()

Removes all objects from the related object set.

To assign the members of a related set in one fell swoop, just assign to it from any iterable object. The iterable can contain object instances, or just a list of primary key values. For example:

b = Blog.objects.get(id=1)
b.entry_set = [e1, e2]

 

In this example, e1 ande2 can be full Entry instances, or integer primary key values.

If the clear() method is available, any pre-existing objects will be removed from theentry_set before all objects in the iterable (in this case, a list) are added to the set. If theclear() method isnot available, all objects in the iterable will be added without removing any existing elements.

Each "reverse" operation described in this section has an immediate effect on the database. Every addition, creation and deletion is immediately and automatically saved to the database.

Many-to-many relationships¶

Both ends of a many-to-many relationship get automatic API access to the other end. The API works just as a "backward" one-to-many relationship, above.

The only difference is in the attribute naming: The model that defines theManyToManyField uses the attribute name of that field itself, whereas the "reverse" model uses the lowercased model name of the original model, plus'_set' (just like reverse one-to-many relationships).

An example makes this easier to understand:

e = Entry.objects.get(id=3)
e.authors.all() # Returns all Author objects for this Entry.
e.authors.count()
e.authors.filter(name__contains='John')

a = Author.objects.get(id=5)
a.entry_set.all() # Returns all Entry objects for this Author.

 

Like ForeignKey , ManyToManyField can specifyrelated_name. In the above example, if the ManyToManyField inEntry had specifiedrelated_name='entries', then eachAuthor instance would have anentries attribute instead ofentry_set.

One-to-one relationships¶

One-to-one relationships are very similar to many-to-one relationships. If you define aOneToOneField on your model, instances of that model will have access to the related object via a simple attribute of the model.

For example:

class EntryDetail(models.Model):
    entry = models.OneToOneField(Entry)
    details = models.TextField()

ed = EntryDetail.objects.get(id=2)
ed.entry # Returns the related Entry object.

 

The difference comes in "reverse" queries. The related model in a one-to-one relationship also has access to a Manager object, but that Manager represents a single object, rather than a collection of objects:

e = Entry.objects.get(id=2)
e.entrydetail # returns the related EntryDetail object

If no object has been assigned to this relationship, Django will raise aDoesNotExist exception.

Instances can be assigned to the reverse relationship in the same way as you would assign the forward relationship:

e.entrydetail = ed

 

How are the backward relationships possible? ¶

Other object-relational mappers require you to define relationships on both sides. The Django developers believe this is a violation of the DRY (Don't Repeat Yourself) principle, so Django only requires you to define the relationship on one end.

But how is this possible, given that a model class doesn't know which other model classes are related to it until those other model classes are loaded?

The answer lies in the INSTALLED_APPS setting. The first time any model is loaded, Django iterates over every model inINSTALLED_APPS and creates the backward relationships in memory as needed. Essentially, one of the functions ofINSTALLED_APPS is to tell Django the entire model domain.

Queries over related objects¶

Queries involving related objects follow the same rules as queries involving normal value fields. When specifying the value for a query to match, you may use either an object instance itself, or the primary key value for the object.

For example, if you have a Blog object b withid=5, the following three queries would be identical:

Entry.objects.filter(blog=b) # Query using object instance
Entry.objects.filter(blog=b.id) # Query using id from instance
Entry.objects.filter(blog=5) # Query using id directly

 

 

 

Falling back to raw SQL ¶

If you find yourself needing to write an SQL query that is too complex for Django's database-mapper to handle, you can fall back on writing SQL by hand. Django has a couple of options for writing raw SQL queries; seePerforming raw SQL queries.

Finally, it's important to note that the Django database layer is merely an interface to your database. You can access your database via other tools, programming languages or database frameworks; there's nothing Django-specific about your database.