mirror of
https://github.com/django/django.git
synced 2024-12-30 13:05:45 +00:00
259 lines
9.8 KiB
Plaintext
259 lines
9.8 KiB
Plaintext
=========================
|
|
Related objects reference
|
|
=========================
|
|
|
|
.. currentmodule:: django.db.models.fields.related
|
|
|
|
.. class:: RelatedManager
|
|
|
|
A "related manager" is a manager used in a one-to-many or many-to-many
|
|
related context. This happens in two cases:
|
|
|
|
* The "other side" of a :class:`~django.db.models.ForeignKey` relation.
|
|
That is::
|
|
|
|
from django.db import models
|
|
|
|
|
|
class Blog(models.Model):
|
|
# ...
|
|
pass
|
|
|
|
|
|
class Entry(models.Model):
|
|
blog = models.ForeignKey(Blog, on_delete=models.CASCADE, null=True)
|
|
|
|
In the above example, the methods below will be available on
|
|
the manager ``blog.entry_set``.
|
|
|
|
* Both sides of a :class:`~django.db.models.ManyToManyField` relation
|
|
::
|
|
|
|
class Topping(models.Model):
|
|
# ...
|
|
pass
|
|
|
|
|
|
class Pizza(models.Model):
|
|
toppings = models.ManyToManyField(Topping)
|
|
|
|
In this example, the methods below will be available both on
|
|
``topping.pizza_set`` and on ``pizza.toppings``.
|
|
|
|
.. method:: add(*objs, bulk=True, through_defaults=None)
|
|
.. method:: aadd(*objs, bulk=True, through_defaults=None)
|
|
|
|
*Asynchronous version*: ``aadd``
|
|
|
|
Adds the specified model objects to the related object set.
|
|
|
|
Example:
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
>>> e = Entry.objects.get(id=234)
|
|
>>> b.entry_set.add(e) # Associates Entry e with Blog b.
|
|
|
|
In the example above, in the case of a
|
|
:class:`~django.db.models.ForeignKey` relationship,
|
|
:meth:`QuerySet.update() <django.db.models.query.QuerySet.update>`
|
|
is used to perform the update. This requires the objects to already be
|
|
saved.
|
|
|
|
You can use the ``bulk=False`` argument to instead have the related
|
|
manager perform the update by calling ``e.save()``.
|
|
|
|
Using ``add()`` with a many-to-many relationship, however, will not
|
|
call any ``save()`` methods (the ``bulk`` argument doesn't exist), 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, which will
|
|
trigger ``pre_add`` and ``post_add`` actions.
|
|
|
|
Using ``add()`` on a relation that already exists won't duplicate the
|
|
relation, but it will still trigger signals.
|
|
|
|
For many-to-many relationships ``add()`` accepts either model instances
|
|
or field values, normally primary keys, as the ``*objs`` argument.
|
|
|
|
Use the ``through_defaults`` argument to specify values for the new
|
|
:ref:`intermediate model <intermediary-manytomany>` instance(s), if
|
|
needed. You can use callables as values in the ``through_defaults``
|
|
dictionary and they will be evaluated once before creating any
|
|
intermediate instance(s).
|
|
|
|
.. versionchanged:: 4.2
|
|
|
|
``aadd()`` method was added.
|
|
|
|
.. method:: create(through_defaults=None, **kwargs)
|
|
.. method:: acreate(through_defaults=None, **kwargs)
|
|
|
|
*Asynchronous version*: ``acreate``
|
|
|
|
Creates a new object, saves it and puts it in the related object set.
|
|
Returns the newly created object:
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
>>> e = b.entry_set.create(
|
|
... headline="Hello", body_text="Hi", pub_date=datetime.date(2005, 1, 1)
|
|
... )
|
|
|
|
# No need to call e.save() at this point -- it's already been saved.
|
|
|
|
This is equivalent to (but simpler than):
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> 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)
|
|
|
|
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``.
|
|
|
|
Use the ``through_defaults`` argument to specify values for the new
|
|
:ref:`intermediate model <intermediary-manytomany>` instance, if
|
|
needed. You can use callables as values in the ``through_defaults``
|
|
dictionary.
|
|
|
|
.. versionchanged:: 4.1
|
|
|
|
``acreate()`` method was added.
|
|
|
|
.. method:: remove(*objs, bulk=True)
|
|
.. method:: aremove(*objs, bulk=True)
|
|
|
|
*Asynchronous version*: ``aremove``
|
|
|
|
Removes the specified model objects from the related object set:
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
>>> e = Entry.objects.get(id=234)
|
|
>>> b.entry_set.remove(e) # Disassociates Entry e from Blog b.
|
|
|
|
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.
|
|
|
|
For many-to-many relationships ``remove()`` accepts either model
|
|
instances or field values, normally primary keys, as the ``*objs``
|
|
argument.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
For many-to-many relationships, the ``bulk`` keyword argument doesn't
|
|
exist.
|
|
|
|
.. versionchanged:: 4.2
|
|
|
|
``aremove()`` method was added.
|
|
|
|
.. method:: clear(bulk=True)
|
|
.. method:: aclear(bulk=True)
|
|
|
|
*Asynchronous version*: ``aclear``
|
|
|
|
Removes all objects from the related object set:
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> b = Blog.objects.get(id=1)
|
|
>>> b.entry_set.clear()
|
|
|
|
Note this doesn't delete the related objects -- it just disassociates
|
|
them.
|
|
|
|
Just like ``remove()``, ``clear()`` is only available on
|
|
:class:`~django.db.models.ForeignKey`\s where ``null=True`` and it also
|
|
accepts the ``bulk`` keyword argument.
|
|
|
|
For many-to-many relationships, the ``bulk`` keyword argument doesn't
|
|
exist.
|
|
|
|
.. versionchanged:: 4.2
|
|
|
|
``aclear()`` method was added.
|
|
|
|
.. method:: set(objs, bulk=True, clear=False, through_defaults=None)
|
|
.. method:: aset(objs, bulk=True, clear=False, through_defaults=None)
|
|
|
|
*Asynchronous version*: ``aset``
|
|
|
|
Replace the set of related objects:
|
|
|
|
.. code-block:: pycon
|
|
|
|
>>> new_list = [obj1, obj2, obj3]
|
|
>>> e.related_set.set(new_list)
|
|
|
|
This method accepts a ``clear`` argument to control how to perform the
|
|
operation. If ``False`` (the default), the elements missing from the
|
|
new set are removed using ``remove()`` and only the new ones are added.
|
|
If ``clear=True``, the ``clear()`` method is called instead and the
|
|
whole set is added at once.
|
|
|
|
For :class:`~django.db.models.ForeignKey` objects, the ``bulk``
|
|
argument is passed on to :meth:`add` and :meth:`remove`.
|
|
|
|
For many-to-many relationships, the ``bulk`` keyword argument doesn't
|
|
exist.
|
|
|
|
Note that since ``set()`` is a compound operation, it is subject to
|
|
race conditions. For instance, new objects may be added to the database
|
|
in between the call to ``clear()`` and the call to ``add()``.
|
|
|
|
For many-to-many relationships ``set()`` accepts a list of either model
|
|
instances or field values, normally primary keys, as the ``objs``
|
|
argument.
|
|
|
|
Use the ``through_defaults`` argument to specify values for the new
|
|
:ref:`intermediate model <intermediary-manytomany>` instance(s), if
|
|
needed. You can use callables as values in the ``through_defaults``
|
|
dictionary and they will be evaluated once before creating any
|
|
intermediate instance(s).
|
|
|
|
.. versionchanged:: 4.2
|
|
|
|
``aset()`` method was added.
|
|
|
|
.. note::
|
|
|
|
Note that ``add()``, ``aadd()``, ``create()``, ``acreate()``,
|
|
``remove()``, ``aremove()``, ``clear()``, ``aclear()``, ``set()``, and
|
|
``aset()`` all apply database changes immediately for all types of
|
|
related fields. In other words, there is no need to call
|
|
``save()``/``asave()`` on either end of the relationship.
|
|
|
|
If you use :meth:`~django.db.models.query.QuerySet.prefetch_related`,
|
|
the ``add()``, ``aadd()``, ``remove()``, ``aremove()``, ``clear()``,
|
|
``aclear()``, ``set()``, and ``aset()`` methods clear the prefetched
|
|
cache.
|