Hi all, One of the new features in 1.2 are signals on m2m operations [1].
Recently, Ticket #13087 was opened questioning the order in which m2m signals are sent. I'm calling for any comments or opinions on exactly how this feature should operate before the current behavior is baked into a release. At the moment, on an m2m operation: * Add is sent *after* the rows have been added * Remove is sent *after* the rows have been removed * Clear is sent *before* the rows are cleared The ordering of the clear signal is the point of contention. The clear signal doesn't get a list of ids - it just flushes the table. This means that if the signal is going to do anything to the list of m2m objects that are being cleared, you need to be able to interrogate the m2m relation before the clear actually happens. This ordering issue doesn't affect add and remove because those signals are given a list of affected IDs. The problem reported by #13087 is that this ordering means you can't set up a signal handler that ensures that the m2m relation always contains a given object. The fact that the clear signal is sent before the rows are cleared means that anything you add will be immediately cleared again. There are 5 options I can see. Option 1: Do nothing. #13087 describes a use case we don't want to support, so we ignore it. Option 2: We add a "cleared" signal that occurs after the clear actually occurs. This solves the use case for #13087, but only adds 1 signal. Option 3: We modify the existing signals so we have a pre-post pair for every signal. This maintains the analog with pre/post save, and gives the most control. For example, on Alex Gaynor has suggested to me that some people might want to use a pre-add signal rather than a post-add signal for cache invalidation since there is a marginally lower chance of getting a race condition. However, signals aren't free -- an unattached signal is roughly equivalent to the overhead of a function call. Option 4: (1), but also move add and remove to be *pre* signals, to alleviate Alex's concern from (3) Option 5: (2), but also move add and remove to be *pre* signals, to alleviate Alex's concern from (3) Opinions? [1] http://code.djangoproject.com/changeset/12223 Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
