Isn't the overhead of a function call negligible compared to executing a database query or opening/closing a connection?
On Mar 27, 10:08 am, 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]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
