However I still believe, as a user of the framework, having 2 signals, before and after, are the best way to go. It is the most intuitive and clear way to provide this functionality.
On Sun, Mar 28, 2010 at 4:44 PM, Firat Can Basarir < [email protected]> wrote: > > > 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.
