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.
