diff options
| author | James Bennett <ubernostrum@gmail.com> | 2008-08-16 10:17:46 +0000 |
|---|---|---|
| committer | James Bennett <ubernostrum@gmail.com> | 2008-08-16 10:17:46 +0000 |
| commit | ceb8fc56af635445cf985eeb60e14a8763dd56cb (patch) | |
| tree | cdeb2c17104ef43a91201dd8568733f9f6317ad9 /docs | |
| parent | cbcc4159342288f6866f2006c30dd16740703049 (diff) | |
Fixed #6915: Documented the fact that QuerySet.delete() may not call delete() methods of individual objects
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8406 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/db-api.txt | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/docs/db-api.txt b/docs/db-api.txt index 61afb14770..3c97de3ca6 100644 --- a/docs/db-api.txt +++ b/docs/db-api.txt @@ -2229,6 +2229,15 @@ For example, this deletes all ``Entry`` objects with a ``pub_date`` year of Entry.objects.filter(pub_date__year=2005).delete() +Keep in mind that this will, whenever possible, be executed purely in +SQL, and so the ``delete()`` methods of individual object instances +will not necessarily be called during the process. If you've provided +a custom ``delete()`` 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 calling ``delete()`` +on each object individually) rather than using the bulk ``delete()`` +method of a ``QuerySet``. + When Django deletes an object, it emulates the behavior of the SQL constraint ``ON DELETE CASCADE`` -- in other words, any objects which had foreign keys pointing at the object to be deleted will be deleted |
