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.

+1 Has anyone tried the patch in production? Is it applied in the trunk?

Replying to ubernostrum:

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.

+1 it's not a feature, it's a bug fix.

Hello. What's the status of this bug? rvdrijst's patch seems to solve all the problems (at least mine, that is), it is neatly written, etc. Is there any reason for not including it into the trunk, thus finally solving this bug? I would really like to see it fixed in 1.2, because it feels really awkward patching django core on production server...

The patch solved my problems as well, but like twold wrote; it's really awkward patching stuff in prod. Status? 1.2?

I found that to have the expected behaviour when using the admin, I had to hack ReverseManyRelatedObjectsDescriptor? and ManyRelatedObjectsDescriptor? in django/db/fields/related.py to replace, in __set__,

        manager = self.__get__(instance)
        manager.clear()
        manager.add(*value)

by

        manager = self.__get__(instance)
        previous=set(manager.all())
        new=set(value)
        added=new-previous
        removed=previous-new
        manager.add(*added)
        manager.remove(*removed)

How does the merger of Alex Gaynor's GSoC project affect this? Patch invalid, no longer needed or neither?

What is Alex Gaynor's GSoC project?

(It's Google Summer of Code project that aimed to bring multiple database support to Django's ORM, refactoring ManyToManyField? along the way)

From a quick roam through the patch and the code @rev 11736 in trunk, it wouldn't take a lot to adapt. Will do if I find the time.

the commenter Mark says in the link posted by aom Seems like it would [solve #5390] since you'd basically be catching signals from the intermediary models. . Will test and report.

@frans - No - the m2m refactor doesn't solve #5390. The signals are at a different granularity. The proposal for this ticket is to send a 'change' signal whenever the m2m field is changed; if you allow signals on the m2m intermediate, you get a signal for each and every object you assign. So -

author.books = [1,2,3,4]

Would generate 4 signals if you listened to the intermediate model, but 1 based on the proposal from this ticket.

It is for this reason that save and delete signals on auto-generated m2m models are explicitly disabled.

I know that part of the code, I can help if you do not find the time frans.

added the patch. Seems to be passing tests (with only a quick try) ok. I didn't add the change mentioned in my comment above with replacing in __set__ clear and add by add and remove. It is a question of religion, I guess. Do we consider set should clear/add what you set, or add/remove the corresponding entries? I guess clear/add makes slightly less DB access. It makes sense for me to do add and remove instead of clear and add (because clear causes in one of my apps to delete some objects based on clear that I really don't want to see deleted each time the admin sets the m2m field) but if you guys have a different opinion, I'm happy with that. What shall we do?

It looks like tests are missing from your patch (don't know if it's intentional though).

No opinion about clear/add/remove, I'm not sure I get all elements to understand.

thks Ludovico, this time with the tests

This is really a great patch! However, when this signal is used in admin, as the setattr method is called in function save_form_data, Django would removed everything in a ManyToManyField?, and then add every object back. Thus the remove method provided in this would not be called in admin view. This is very confusing and misleading IMHO. I think someone would need to make some change to some of the functions in django/db/models/fields/related.py to make sure the remove method is called properly.

@xiaket : see my comment on 11/08/09 12:35:51, it precisely covers that. If you add the change I mention there, it will behave as you describe/expect.

Replying to frans:

I'm so sorry, after my stupid post I found your solution, which, I boldly suggest, should have been included in the last patch.

following xiaket's private email, solution in comment above should be amended to deal better with clear()

However, I think there is a minor problem about you approach: the clear signal would not be correctly issued. So I modified the code:

        manager = self.__get__(instance)
        previous=set(manager.all())
        new=set(value)
        if not new:
            manager.clear()
        else:
            added = new - previous
            removed = previous - new
            if removed:
                manager.remove(*removed)
            if added:
                manager.add(*added)

will update the patch as soon as I find time to restore my repository to a clean state...

updated diff with correct clear() management and more recent version of trunk

Note : diff above (5390-against-12033.diff) is not tested yet..

Revised implementation of m2m signals

(In [12223]) Fixed #5390 -- Added signals for m2m operations. Thanks to the many people (including, most recently, rvdrijst and frans) that have contributed to this patch.