remove(*objs) Removes the specified model objects from the related object set: >>> 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_ch

clear() Removes all objects from the related object set: >>> 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.

add(*objs, bulk=True) Adds the specified model objects to the related object set. Example: >>> 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 c

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

FieldFile.url A read-only property to access the file’s relative URL by calling the url() method of the underlying Storage class.

FieldFile.size The result of the underlying Storage.size() method.

FieldFile.open(mode='rb') [source] Opens or reopens the file associated with this instance in the specified mode. Unlike the standard Python open() method, it doesn’t return a file descriptor. Since the underlying file is opened implicitly when accessing it, it may be unnecessary to call this method except to reset the pointer to the underlying file or to change the mode.

FieldFile.save(name, content, save=True) [source] This method takes a filename and file contents and passes them to the storage class for the field, then associates the stored file with the model field. If you want to manually associate file data with FileField instances on your model, the save() method is used to persist that file data. Takes two required arguments: name which is the name of the file, and content which is an object containing the file’s contents. The optional save argument

FieldFile.name The name of the file including the relative path from the root of the Storage of the associated FileField.

class FieldFile [source] When you access a FileField on a model, you are given an instance of FieldFile as a proxy for accessing the underlying file. The API of FieldFile mirrors that of File, with one key difference: The object wrapped by the class is not necessarily a wrapper around Python’s built-in file object. Instead, it is a wrapper around the result of the Storage.open() method, which may be a File object, or it may be a custom storage’s implementation of the File API. In addition to