Actually, not that I think about this again, the rationale behind my original proposal was this: since nulls are included in the output anyway we may as well count them. This way there are no surprises about what's counted and what's not. And users who do not want to count nulls should apply query set filters. Does this make sense?
On Fri, Jan 28, 2011 at 11:12 AM, Sergiy Kuzmenko <[email protected]> wrote: > Thanks for you input Russ. Yes, Count("*") does look cleaner but > (based on a quick glance on the code) may require some serious > rewiring. I'll give some more thought as to how this may be > accomplished. Should I create a new ticket then or reopening the one I > already put is fine? > > Cheers > Sergiy > > On Fri, Jan 28, 2011 at 10:36 AM, Russell Keith-Magee > <[email protected]> wrote: >> On Fri, Jan 28, 2011 at 11:05 PM, Sergiy Kuzmenko <[email protected]> >> wrote: >>> A couple of points regarding this: >>> http://code.djangoproject.com/ticket/15183#comment:1. >>> >>> If nulls should not be counted then then they should be excluded from >>> results but they are not. >>> >>> You always get an entry for nulls (if they >>> are present) with zero count which if you need them is a problem and >>> if you don't - it's just a completely useless entry and you must do >>> some extra coding to get rid of it. That's what I find most confusing >>> about current Count() implementation. >>> >>> Conceptual leakage apart, SQL gives user a choice as to how items >>> should be counted, whereas Django's ORM does not. Neither it is >>> obvious what goes under the hood until one starts looking into SQL >>> log. >>> >>> I think this should be fixed or at least somehow clarified. Possible >>> ways to address this are the following (in order of my preference): >>> >>> 1) Change current implementation as proposed in my ticket. >> >> You're complaining that Django's ORM doesn't give you a choice, but >> your proposal on #15183 wasn't to provide another choice. It was to >> enforce one particular choice -- a different one to the one that is >> currently implemented. >> >>> 2) Allow user to control this behavoiur, e.g.,: Count("my_value", >>> include_null=True) >> >> This is more appealing to me. As an alternative syntax, I would >> suggest Count("*") - or, to keep the SQL -specific syntax out of the >> ORM, just Count(). Count(*) is already supported internally (that's >> how MyModel.objects.count() is implemented), so it should be a lot >> less invasive than your original proposal. >> >>> 3) Clarify current behaviour in documentation: that nulls are never >>> counted but if present are part of result set with zero count. >> >> Regardless of the decision on adding a new feature, this is probably a >> good idea. >> >>> BTW, I did bring this to django-dev but due to lack of response >>> concluded that there were no objections to my proposal: >>> http://groups.google.com/group/django-developers/browse_thread/thread/9821b79da9d849e?hl=en. >>> Perhaps I wasn't just clear enough. >> >> I'm not sure it's fair to read that thread as "no objections". It >> could equally be read as "no support". There's only one other >> participant in the thread, and he's seeking clarification. >> >> 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. >> >> > -- 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.
