On Sat, Mar 27, 2010 at 8:08 PM, Russell Keith-Magee <[email protected] > wrote:
> 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]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > I was thinking hard to come up with an alternative and I have the following (I am not sure this is good API design but a single signal can handle both cases this way): How about sending a pre-signal and including an object as a parameter which lets the user execute the m2m operation. With a single signal, you can do the post-signal stuff (if you need it) after executing the operation in your listener. If the operation is NOT executed after the signal is handled by the listener, the original dispatcher can execute it and continue without a post-signal. Firat -- 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.
