Skip to content

djangodocs

Django 1.10
  • 6.1 current
  • 6.0
  • 5.2 LTS
  • 5.1 unsupported
  • 5.0 unsupported
  • 4.2 unsupported
  • 4.1 unsupported
  • 4.0 unsupported
  • 3.2 unsupported
  • 3.1 unsupported
  • 3.0 unsupported
  • 2.2 unsupported
  • 2.1 unsupported
  • 2.0 unsupported
  • 1.11 unsupported
  • 1.10 unsupported
  • 1.9 unsupported
日本語
  • English
  • Français
  • 日本語
  • Bahasa Indonesia
  • Português (Brasil)
  • Español
  • Ελληνικά
  • Polski
Documentation contents
  • Django ドキュメント
  • さぁ始めましょう。
  • Django を使う
  • 「How-to」ガイド
  • Django FAQ よくある質問
  • API Reference
    • アプリケーション
    • System check framework
    • ビルトインのクラスベースビュー API
    • クリックジャッキング対策
    • contrib packages
    • クロスサイトリクエストフォージェリ (CSRF) 対策
    • Databases
    • django-admin and manage.py
    • Django Exceptions
    • File handling
    • フォーム
    • ミドルウェア
    • マイグレーション操作
    • モデル
      • モデルフィールドリファレンス
      • Model _meta API
      • Related objects reference
      • Model クラスのリファレンス
      • Model Meta options
      • モデルインスタンスリファレンス
      • QuerySet API reference
      • Lookup API reference
      • Query Expressions
      • Conditional Expressions
      • Database Functions
    • リクエストとレスポンスのオブジェクト
    • SchemaEditor
    • 設定
    • Signals
    • テンプレート
    • TemplateResponse and SimpleTemplateResponse
    • Unicode data
    • django.urls utility functions
    • django.conf.urls utility functions
    • Django Utils
    • バリデータ
    • Built-in Views
  • メタドキュメントとその他
  • 用語集
  • リリースノート
  • Django internals
Django 1.10 is no longer supported. It receives no security fixes. Use it for reference only. Latest release
Japanese translation. Untranslated passages appear in English. 27.0% Help translate
  1. Django 1.10
  2. API Reference
  3. モデル

Related objects referenceLink to this heading#

class RelatedManagerLink to this definition#

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 ForeignKey relation. That is:

    Code
    from django.db import models
    
    class Reporter(models.Model):
        # ...
        pass
    
    class Article(models.Model):
        reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)
    

    In the above example, the methods below will be available on the manager reporter.article_set.

  • Both sides of a ManyToManyField relation:

    Code
    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.

add(*objs, bulk=True)Link to this definition#

Adds the specified model objects to the related object set.

実装例:

Code
>>> 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 ForeignKey relationship, 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, but rather create the relationships using QuerySet.bulk_create(). If you need to execute some custom logic when a relationship is created, listen to the m2m_changed signal.

Changed in Django 1.9

The bulk parameter was added. In older versions, foreign key updates were always done using save(). Use bulk=False if you require the old behavior.

create(**kwargs)Link to this definition#

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

Code
>>> 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 much simpler than):

Code
>>> 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.

remove(*objs)Link to this definition#

Removes the specified model objects from the related object set:

Code
>>> 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 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 QuerySet.delete() which means no model save() methods are called; listen to the m2m_changed signal if you wish to execute custom code when a relationship is deleted.

For 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 ForeignKey doesn't have null=True, this is invalid.

For 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 pre_save and post_save signals and comes at the expense of performance.

clear()Link to this definition#

Removes all objects from the related object set:

Code
>>> 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 ForeignKeys where null=True and it also accepts the bulk keyword argument.

set(objs, bulk=True, clear=False)Link to this definition#

New in Django 1.9

Replace the set of related objects:

Code
>>> 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.

The bulk argument is passed on to add().

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

注釈

Note that add(), create(), remove(), clear(), and set() 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.

Also, if you are using an intermediate model for a many-to-many relationship, then the add(), create(), remove(), and set() methods are disabled.

Direct AssignmentLink to this heading#

A related object set can be replaced in bulk with one operation by assigning a new iterable of objects to it:

Code
>>> new_list = [obj1, obj2, obj3]
>>> e.related_set = new_list

If the foreign key relationship has null=True, then the related manager will first 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.

Changed in Django 1.9

In earlier versions, direct assignment used to perform clear() followed by add(). It now performs a set() with the keyword argument clear=False.

Deprecated since Django 1.10

バージョン 1.10 で非推奨: Direct assignment is deprecated in favor of the set() method:

Code
>>> e.related_set.set([obj1, obj2, obj3])

これにより、暗黙の保存による代入によってもたらされる混乱を防ぐことができます。

View as Markdown Edit this page on GitHub Official version
PreviousModel _meta API NextModel クラスのリファレンス

On this page

  • Direct Assignment

An unofficial rendering of the Django documentation.

Not affiliated with or endorsed by the Django Software Foundation. The documentation is copyright © Django Software Foundation and individual contributors, and is used under the BSD 3-Clause licence. “Django” is a trademark of the Django Software Foundation.

This translation is the work of the Django i18n community, not of this site. Read the official documentation at docs.djangoproject.com.

👋 Jason Cartwright