#15183: wont fix follow up

[Sergiy Kuzmenko]

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.

2) Allow user to control this behavoiur, e.g.,: Count("my_value",
include_null=True)

3) Clarify current behaviour in documentation: that nulls are never
counted but if present are part of result set with zero count.

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.

Cheers
Sergiy

[Russell Keith-Magee]

On Fri, Jan 28, 2011 at 11:05 PM, Sergiy Kuzmenko <s.kuz...@gmail.com> 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 %-)

[Sergiy Kuzmenko]

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

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

[Sergiy Kuzmenko]

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?