I feel that returning an empty queryset where value=None is just laziness. Yes, maybe it will break things, but maybe those things are meant to be broken. You could just as easily say myfield__exact which would work as it would before, and leave the default to isnull for None. This is similar to how you can (I believe) say myfield=[list] and it does myfield__in.
On Jul 17, 5:54 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 7/17/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 2007-07-17 at 07:28 +0200, Michael Radziej wrote: > > [...] > > > While interpreting __exact=None as "WHERE ... = NULL" might confuse new > > > users, it is probably just what users used to SQL expect (at least for me > > > it > > > comes quite naturally). > > > I wasn't convinced by this argument back in October and I still aren't. > > I suppose if I had to defend it now, I would rephrase this argument > slightly. I would say that =NULL _is_ a different query to IS NULL. > API beauty and Python symmetry is important, and I agree that in the > Python context, exact=None reads as isnull=True. However, IMHO so is > being able to touch as many SQL queries as possible. I'd like to think > that if a developer needs to write a particular query, the Django ORM > will get them there. > > However, looking at the issue again, I'm not as convinced as I > obviously was in October. It's entirely possible I was just too close > to the underlying implementation at the time, and was seeing edge > cases that, in practice, don't exist. Mea culpa. > > > I'm not convinced about the huge negative impact of the change, either. > > Not sure I agree here. Any query that has been set up as > filter(foo=value) will be expecting no results to be returned if value > is None. If we make _equals=None map to __isnull=True, the same query > could start returning results if field foo has null=True in its > definition. > > To me, this sounds like a big enough backwards compatibility problem > to be a concern. > > This isn't to say I'm completely opposed to making the change - just > that we shouldn't underestimate how big a change it could be. > > For the record, I'm a weak +0 on making the change. IMHO, the > backwards compatibility objections are significant enough to warrant > caution, but I can see the value in the syntactic change. I'm more > than happy to leave the call to someone else, and I could happily live > with either outcome. > > > There was *one* use-case touted (by Deryck Hodge) in the original > > thread. > > Deryck's use case is slightly different, to my reading. I believe he > was talking about the original behaviour, where __exact=None was a > completely ignored operation - which was the behaviour causing dramas > for related objects. > > 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 django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
