Add signals to ManyRelatedManager

better patch, checked against django regression tests

Sending source_col and target_col to the dispatcher is probably unnecessary.

Cleaner variant of patch #2

Test models

Test cases

I attached a cleaner patch that does away with sending the field names, and some test cases with the necessary models.

#1069 and #2861 were duplicates.

#3854 was a duplicate.

I am using this patch to monitor user-group mapping in contrib.auth, and it works without any glitches.

I am also using the patch to monitor contrib.auth user-group relationships with no problems.

I'm using the patch quite a lot and up to now it works great. I really think this functionality should go into core, simply because it complements the other signals nicely and enables a developer to fully monitor all database changes (given that the orm is used).

Patch misses documentation. Notes about m2m signals should go into db-api.txt, section Many-to-many relationships.

patch for the db-api docs

As I said before the patch works, but I just found a piece of missing functionality. By using related_name it is possible to have 2 or more Many2many fields to the same model, but using the dispatcher there is no way to distinguish between the relations, or am I missing something here? A possible solution would be to send the the name of the join_table along with the signal, but that seems rather hackish.

It's possible to add one parameter to RelatedManager.__init__() — field_name, and send it along with the signal. With the help of field_name we can easily get field instance itself: [f for f in MyModel._meta.many_to_many if f.name == field_name][0], or access RelatedManager: getattr(instance, field_name).

related.diff with added field_name parameter (signals and dispatcher are already imported)

m2m signals patch, updated against signals refactoring

+1 on this, it would be so useful right now for me; too bad it isn't in yet :(

#6778 was a duplicate

I have started a discussion on django-developers concerning this ticket and the limitations I have encountered: http://groups.google.com/group/django-developers/browse_thread/thread/afe6ad7994d868ba

Hopefully, this will push development and get this feature in the 1.1alhpa scheduled for january '09.

If you are interested, please read and comment there. If discussion is fruitful, I will claim the ticket and improve the patch, docs and tests.

Additionally, not related to the functionality but to the documentation: the db-api.txt is not the right place for signal documentation (there is no talk of pre/post_save signals there either). The correct place seems docs/ref/signals.txt. Also, not only the names of the signals, but also the extra arguments will need to be described.

A complete patch with code, docs and tests for an m2m_changed signal.

I have attached a new patch that combines the changes to the code, the documentation and the tests in one file.

The biggest change is that there is now only one signal, m2m_changed, that has an 'action' parameter (based on a comment of Malcolm Tredinnick. The other parameters have changed somewhat, please discuss problems/suggestions on the django-developer thread mentioned above, where I have also posted a short explanation of the new parameters.

And thanks to Ludovico for the initial implementation.

Milestone post-1.0 deleted

+1 Please include this fix in the upcoming release. I'm having to do some awful code hacks to get around this.

Replying to wmdmark:

+1 Please include this fix in the upcoming release. I'm having to do some awful code hacks to get around this.

You do realize the feature freeze for 1.1 has passed already, right (in fact, 1.1 is behind schedule because we delayed a bit for a late-running feature)? No new feature checkins will happen until after the release, at which point proposals for inclusion in 1.2 will open.

If you're really interested in getting a feature into Django, it's in your best interest to get involved on the developers' list and pay attention to the release schedule.