2008-08-24 00:25:40 +02:00
|
|
|
=========================
|
|
|
|
Related objects reference
|
|
|
|
=========================
|
|
|
|
|
2010-05-11 16:12:08 +02:00
|
|
|
.. currentmodule:: django.db.models.fields.related
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2010-05-17 18:32:37 +02:00
|
|
|
.. class:: RelatedManager
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 20:30:54 +02:00
|
|
|
|
2010-11-26 13:40:09 +01:00
|
|
|
A "related manager" is a manager used in a one-to-many or many-to-many
|
2010-05-17 18:32:37 +02:00
|
|
|
related context. This happens in two cases:
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
* The "other side" of a :class:`~django.db.models.ForeignKey` relation.
|
|
|
|
That is::
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2013-05-18 12:12:26 +02:00
|
|
|
from django.db import models
|
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
class Reporter(models.Model):
|
2013-05-18 12:12:26 +02:00
|
|
|
# ...
|
|
|
|
pass
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
class Article(models.Model):
|
|
|
|
reporter = models.ForeignKey(Reporter)
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
In the above example, the methods below will be available on
|
|
|
|
the manager ``reporter.article_set``.
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
* Both sides of a :class:`~django.db.models.ManyToManyField` relation::
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
class Topping(models.Model):
|
2013-05-18 12:12:26 +02:00
|
|
|
# ...
|
|
|
|
pass
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
class Pizza(models.Model):
|
|
|
|
toppings = models.ManyToManyField(Topping)
|
Fixed a whole bunch of small docs typos, errors, and ommissions.
Fixes #8358, #8396, #8724, #9043, #9128, #9247, #9267, #9267, #9375, #9409, #9414, #9416, #9446, #9454, #9464, #9503, #9518, #9533, #9657, #9658, #9683, #9733, #9771, #9835, #9836, #9837, #9897, #9906, #9912, #9945, #9986, #9992, #10055, #10084, #10091, #10145, #10245, #10257, #10309, #10358, #10359, #10424, #10426, #10508, #10531, #10551, #10635, #10637, #10656, #10658, #10690, #10699, #19528.
Thanks to all the respective authors of those tickets.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@10371 bcc190cf-cafb-0310-a4f2-bffc1f526a37
2009-04-03 20:30:54 +02:00
|
|
|
|
2011-10-14 02:12:01 +02:00
|
|
|
In this example, the methods below will be available both on
|
|
|
|
``topping.pizza_set`` and on ``pizza.toppings``.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
.. method:: add(obj1, [obj2, ...])
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Adds the specified model objects to the related object set.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Example::
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
|
|
>>> e = Entry.objects.get(id=234)
|
|
|
|
>>> b.entry_set.add(e) # Associates Entry e with Blog b.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
In the example above, in the case of a
|
|
|
|
:class:`~django.db.models.ForeignKey` relationship,
|
|
|
|
``e.save()`` is called by the related manager to perform the update.
|
|
|
|
Using ``add()`` with a many-to-many relationship, however, will not
|
|
|
|
call any ``save()`` methods, but rather create the relationships
|
|
|
|
using :meth:`QuerySet.bulk_create()
|
|
|
|
<django.db.models.query.QuerySet.bulk_create>`. If you need to execute
|
|
|
|
some custom logic when a relationship is created, listen to the
|
|
|
|
:data:`~django.db.models.signals.m2m_changed` signal.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
.. method:: create(**kwargs)
|
2013-07-12 12:19:16 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Creates a new object, saves it and puts it in the related object set.
|
|
|
|
Returns the newly created object::
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
|
|
>>> e = b.entry_set.create(
|
|
|
|
... headline='Hello',
|
|
|
|
... body_text='Hi',
|
|
|
|
... pub_date=datetime.date(2005, 1, 1)
|
|
|
|
... )
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
# No need to call e.save() at this point -- it's already been saved.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
This is equivalent to (but much simpler than)::
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
|
|
>>> e = Entry(
|
|
|
|
... blog=b,
|
|
|
|
... headline='Hello',
|
|
|
|
... body_text='Hi',
|
|
|
|
... pub_date=datetime.date(2005, 1, 1)
|
|
|
|
... )
|
|
|
|
>>> e.save(force_insert=True)
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Note that there's no need to specify the keyword argument of the model
|
|
|
|
that defines the relationship. In the above example, we don't pass the
|
|
|
|
parameter ``blog`` to ``create()``. Django figures out that the new
|
|
|
|
``Entry`` object's ``blog`` field should be set to ``b``.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
.. method:: remove(obj1, [obj2, ...])
|
2010-05-11 16:12:08 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Removes the specified model objects from the related object set::
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
|
|
>>> e = Entry.objects.get(id=234)
|
|
|
|
>>> b.entry_set.remove(e) # Disassociates Entry e from Blog b.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Similar to :meth:`add()`, ``e.save()`` is called in the example above
|
|
|
|
to perform the update. Using ``remove()`` with a many-to-many
|
|
|
|
relationship, however, will delete the relationships using
|
|
|
|
:meth:`QuerySet.delete()<django.db.models.query.QuerySet.delete>` which
|
|
|
|
means no model ``save()`` methods are called; listen to the
|
|
|
|
:data:`~django.db.models.signals.m2m_changed` signal if you wish to
|
|
|
|
execute custom code when a relationship is deleted.
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
For :class:`~django.db.models.ForeignKey` objects, this method only
|
|
|
|
exists if ``null=True``. If the related field can't be set to ``None``
|
|
|
|
(``NULL``), then an object can't be removed from a relation without
|
|
|
|
being added to another. In the above example, removing ``e`` from
|
|
|
|
``b.entry_set()`` is equivalent to doing ``e.blog = None``, and because
|
|
|
|
the ``blog`` :class:`~django.db.models.ForeignKey` doesn't have
|
|
|
|
``null=True``, this is invalid.
|
2013-07-12 12:19:16 +02:00
|
|
|
|
2013-11-21 18:14:16 +01:00
|
|
|
.. versionchanged 1.7::
|
|
|
|
|
|
|
|
For :class:`~django.db.models.ForeignKey` objects, this method accepts
|
|
|
|
a ``bulk`` argument to control how to perform the operation.
|
|
|
|
If ``True`` (the default), ``QuerySet.update()`` is used.
|
|
|
|
If ``bulk=False``, the ``save()`` method of each individual model
|
|
|
|
instance is called instead. This triggers the
|
|
|
|
:data:`~django.db.models.signals.pre_save` and
|
|
|
|
:data:`~django.db.models.signals.post_save` signals and comes at the
|
|
|
|
expense of performance.
|
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
.. method:: clear()
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Removes all objects from the related object set::
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
|
|
>>> b.entry_set.clear()
|
2008-08-24 00:25:40 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Note this doesn't delete the related objects -- it just disassociates
|
|
|
|
them.
|
2010-05-17 18:32:37 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Just like ``remove()``, ``clear()`` is only available on
|
2013-11-21 18:14:16 +01:00
|
|
|
:class:`~django.db.models.ForeignKey`\s where ``null=True`` and it also
|
|
|
|
accepts the ``bulk`` keyword argument.
|
2010-05-17 18:32:37 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
.. note::
|
2013-09-06 18:37:08 +02:00
|
|
|
|
2013-09-06 20:44:40 +02:00
|
|
|
Note that ``add()``, ``create()``, ``remove()``, and ``clear()`` all
|
|
|
|
apply database changes immediately for all types of related fields. In other
|
|
|
|
words, there is no need to call ``save()`` on either end of the
|
|
|
|
relationship.
|
2013-09-06 18:37:08 +02:00
|
|
|
|
|
|
|
.. _direct-assignment:
|
|
|
|
|
|
|
|
Direct Assignment
|
|
|
|
-----------------
|
|
|
|
|
|
|
|
A related object set can be replaced in bulk with one operation by assigning a
|
|
|
|
new iterable of objects to it::
|
|
|
|
|
|
|
|
>>> new_list = [obj1, obj2, obj3]
|
2013-10-10 22:42:30 +02:00
|
|
|
>>> e.related_set = new_list
|
2013-09-06 18:37:08 +02:00
|
|
|
|
|
|
|
If the foreign key relationship has ``null=True``, then the related manager
|
|
|
|
will first call ``clear()`` to disassociate any existing objects in the related
|
|
|
|
set before adding the contents of ``new_list``. Otherwise the objects in
|
|
|
|
``new_list`` will be added to the existing related object set.
|