Add signals to ManyRelatedManager
|Reported by:||Owned by:||rvdrijst|
|Component:||Database layer (models, ORM)||Version:||master|
|Severity:||Normal||Keywords:||manytomanyfield feature signals|
|Cc:||sjulean@…, django@…, sean@…, patrick.lauber@…, chpapa@…, thiago.salves@…, oliver@…, rvdrijst, piranha@…, palewire@…, maxischmeii@…, django@…, lvscar@…, brent.hagany@…, matiassurdi@…, Mika Marttila, niran@…, eromirou, tomasz.elendt@…, django@…, francois@…, David Larlet, chris@…, django.tickets@…, muanis@…||Triage Stage:||Design decision needed|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
There's currently no way to run some custom code when the ManyRelatedManager adds, removes, or clears objects. Extending the ManyRelatedManager is very hard, since it's dynamically created each time, and the ManyRelatedObjectsDescriptor prevents any access to it from its container class. A simple solution is to add three signals, and hook them into the dispatching mechanism when adding, removing, or deleting a related object.
A typical use case for attaching custom code to a MayRelatedManager is blog categories: having a num_posts field in the Category models, and updating it each time a category is added/removed to/from a post, speeds up considerably a simple category list that excludes empty categories, and counts only published posts. The difference in resource usage is huge -- one query with two simple filters against one query for the list, plus one for each category (yes, you can cache the output, but think eg of a multi-blog app where posts are frequently updated, and a cache miss is very expensive), and the resulting code is much simpler.
A simple patch is attached to this ticket, I have tested it briefly against some of my models and it appears to work ok.
Change History (77)
comment:19 Changed 8 years ago by
|Patch needs improvement:||set|
comment:21 Changed 8 years ago by
|Owner:||changed from nobody to rvdrijst|
|Patch needs improvement:||unset|
|Status:||new → assigned|