I recently found the time to create a better patch for the m2m signals, including some tests and documentation and have posted this patch on http://code.djangoproject.com/ticket/5390 I have taken into account Malcom's suggestions resulting in one signal called m2m_changed that has the following arguments:
sender The model class containing the ManyToManyField instance The instance whose many-to-many relation is updated. action A string indicating the type of update that is done on the relation: "add", "remove" or "clear". model The class of the objects that are added to, removed from or cleared from the relation. field_name The name of the ManyToManyField in the sender class, can be used in case of multiple m2m fields to the same model. reverse False if the 'normal' side of the relation is updated, True if the reverse side (i.e. on the related model) is used. objects With the "add" and "remove" action, this is a list of objects that have been added to or removed from the relation. The class of these objects is given in the model argument. For the "clear" action, this is None . The signal is emitted _after_ the change for the "add" and "remove" action, and _before_ the change for the "clear" action. For an example see the docs and tests in the patch, suggestions for improvements are of course still appreciated, so please discuss! Hopefully this will speed up inclusion of this feature into django. Regards, -Robin On Dec 21 2008, 6:26 am, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Fri, 2008-12-19 at 08:42 -0800, rvdrijst wrote: > > I know there has already been some discussion about addingsignalsto > > the ManyRelatedManager so that add(), remove() and clear() on m2m > > relations emitsignals. This functionality, [ORM-18] in the v1.1 > > roadmap, would complement the behavior of pre/post_save and pre/ > > post_delete very nicely and provide a easy and transparent way to > > track changes to m2m relationships. > > Since I really like to have this functionality for a project I am > > working on, I'm trying to push this feature for v1.1alpha. However, > > some design decisions need to be made, which is why I am starting this > > discussion. > > > The ticket for this functionality > > ishttp://code.djangoproject.com/ticket/5390 > > which has a patch that works to some extent. It adds threesignals: > > m2m_add_items, m2m_remove_items and m2m_clear_items. Extra arguments > > to the signal are the instance on which the field is accessed, the > > field_name of the m2m field and the list of added/removed objects. > > The main problem with the patch is the unintuitive sender ofsignals. > > The signal is sent by the _related_ model, not the model containing > > the ManyToManyField. For example: > > > class Car(models.Model) > > parts = models.ManyToManyField('Part') > > > class Part(models.Model) > > pass > > > Now if we want to handle the signal sent by some_car.parts.add > > (some_part), we would have to connect the handler to Part: > >signals.m2m_add_items(add_handler_func, Part) > > To me, this is not very intuitive. I would like to connect to Car, > > since that model has the 'parts' field, so this is something I'm > > suggesting to change in the patch (not that hard to do). > > I don't have answers to all the issues you raise in this message, but I > agree with you here. The ManyToMany is part of Car, so that should be > the model that is passed as the model, if at all possible. You might > want to consider passing the other end's model as well, if you can. The > current parameters you list make it sound like it would be fiddly to > work out which m2m was changed on a model that contains more than one of > them. However that washes out in the end, we need to be able to do that. > > I also suspect that threesignalsis about three times more than the > ideal number. A "changed" signal that accepts a parameter for the action > (added, removed, cleared) and a list of what was added or removed in the > former two cases would cut down on the number of newsignalsthat need > to be added. I don't feel too uncomfortable with the overloading of > purpose here, since the signal is really handling "changes to the m2m > field" and the parameters are just identifying variations on that. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
