Hi All,
I've hit upon an interesting bug, which is related to ticket 2737
(currently listed as a feature request, but I think there is an
argument that the requested feature is required as a bug fix).
Consider the following model:
class Poll(models.Model):
name = models.CharField(maxlength=100)
class Choice(models.Model):
name = models.CharField(maxlength=100)
poll = models.ForeignKey(Choice)
Create some dummy data, then run the following sequence of commands:
> p = Poll()
> p.choice_set.all()
i.e., a related manager on unsaved object. This returns _all_ Choice
objects in the database. It turns out that this is because the related
manager is based upon a 'relatedname__pk=%d' % pk_value' query.
However:
> Choice.objects.filter(poll__pk=None)
returns all Choice objects in the database, because any query where
value=None is outright ignored - no error, no warning. As a side note,
this also means that:
> Choice.objects.filter(foo__pk=None)
_also_ returns all choice objects in the database, with no error, even
though foo isn't a valid attribute name.
To me, all three of these behaviours are counterintuitive. To me, the
choice_set of an unsaved object should be empty, pk=None (and, by
extension, id__exact=None) corresponds nicely to id__isnull=True, and
an invalid attribute should always raise an error.
Ticket 2737 requests a feature where __exact=None would be interpreted
as __isnull=True. This would fix all three problems I have described.
The proposed patch isn't correct, but I feel the idea is valid.
As a quick test, I removed line 710 of query.py (the line that exludes
value=None queries), and none of the unit tests failed, so it doesn't
appear that ignoring value=None queries is explicitly required.
Obviously, it is desirable for other query types, like __range=None,
but there hasn't been an explicit test-driven requirement that
value=None queries are ignored. However, this could be an indication
of deficiencies in the regression suite.
Also, fixing this problem is problematic because it encroaches upon
Malcolm's refactor of the QuerySet code.
Comments? Have I missed an obvious problem? Have I missed a ticket in
the database that describes this problem already? Malcolm, can you
comment on the potential impact a short term fix for this problem
would have on your refactor work?
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
-~----------~----~----~----~------~----~------~--~---
