#13087 closed (fixed)
m2m_changed fires before a clear but after add/remove
Reported by: | rcatherman | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.2-beta |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
In db/models/fields/related.py I notice that _add_items and _remove_items perform the db actions and then fire the signal to the m2m_changed listeners. _clear_items fires the signal prior to the db interaction. The result is inconsistent. For my use case, I'd like to have my listener assert a relationship has at least one particular item no matter if it is accidentily cleared. It works on removal, but not on clear because I notice the DELETE happens after my re-INSERT.
I've made the change here and it works as expected now.
Change History (7)
comment:1 by , 15 years ago
milestone: | → 1.2 |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
comment:2 by , 15 years ago
Component: | Uncategorized → Database layer (models, ORM) |
---|
comment:3 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:5 by , 15 years ago
Why not do both? We have pre/post-save, and pre/post-delete. So, pre/post-m2m_changed would be very much in line with what Django already has.
comment:6 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [12888]) Fixed #13087 -- Modified m2m signals to provide greater flexibility over exactly when notifications are delivered.
This is a BACKWARDS INCOMPATIBLE CHANGE for anyone using the signal names introduced in r12223.
- If you were listening to "add", you should now listen to "post_add".
- If you were listening to "remove", you should now listen to "post_remove".
- If you were listening to "clear", you should now listen to "pre_clear".
You may also want to examine your code to see whether the "pre_add", "pre_remove" or "post_clear" would be better suited to your application.
This certainly needs to be decided before 1.2. The current behaviour is deliberate, and documented as implemented; I need to think about this (preferably with a clear head) to determine if the current behavior is the most desirable.