Hi all,
We've encountered a funny bug in our code, which I thought was worth sharing.
I don't think a bug in Django is involved, but I suspect Django could do
better to prevent it.
The issue is with the distinct() method of querysets. Up to Django 1.3, it was
documented as taking no arguments; in Django 1.4, an optional "*fields"
argument was added, to support Postgresql's "DISTINCT ON" feature.
However, in Django 1.3, distinct() did take one argument:
def distinct(self, true_or_false=True):
...
Some of our coders, who apparently only glimpsed at the documentation, made
calls to distinct with one field:
SomeModel.objects.filter(...).distinct('field')
This worked as if distinct() was called with no arguments, because 'field'
evaluates True; it broke with the move to Django 1.4, because we don't use
Postgresql.
Now, of course, Django is not to blame for developers who only read the titles
of the documentation (and documentation for the wrong Django version, to
boot); but I still claim it is a minor gotcha, because the *fields argument was
on the /dev/ version docs for a long time, and many times it is those pages
that come up first in web searches.
I was thinking along the lines of adding, in the 1.3 branch, when the change
was made (that is, in the days before 1.4), some warning for anyone using the
old, undocumented, soon-to-be-gone API; something along the lines of
def distinct(self, true_or_false=True):
if true_or_false is not True:
warn(DeprecationWarning, "this API is about to change")
The issue for this call is moot now, but there may be others like it.
Thoughts?
Thanks,
Shai.
--
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.
