#8025 closed (invalid)
Failed when lookups that span relationships with __isnull.
Reported by: | bear330 | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | dev |
Severity: | Keywords: | isnull, span | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have two records like this:
id user name desc parent type 5, 5, 'My favorites', 'The default group of user's group.', , 1 6, 5, 'My traces', 'The default group of my traces.', 5, 2
When I query it with (user's id = 5):
TraceGroup.objects.filter(user=user, parent__parent__isnull=True)
I got:
[<TraceGroup: My favorites>, <TraceGroup: My traces>]
But the first record (My favorites) is not expected result for me.
I think this is because <My favorites>'s parent is null, parentparentisnull will be matched if parent is null.
I have to do this way to get correct result:
TraceGroup.objects.filter(user=user, parent__isnull=False, parent__parent__isnull=True)
Is this a bug or it should be commented at documentation?
Thanks.
Change History (7)
comment:1 by , 16 years ago
milestone: | 1.0 → 1.0 beta |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
This isn't really a bug, because it's a very normal type of result to expect: if the parent is null, then the "parent's parent" can still be queried, but it will also be null. Otherwise everybody filtering on parent__parent__isnull=True
would have to also test if parent__isnull=True
, which is onerous and almost always what is expected. So your second query is the right way to do what you want and the first is returning the "correct" results for our interpretation.
I'm going to close this as wontfix, but I'll make a small documentation change to try and clarify it.
comment:3 by , 16 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:4 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
comment:5 by , 16 years ago
FWIW despite your concerns about the length, once the docs refactor stuff happens(be it before or after 1.0), it can be put in a better location since the docs will split into multiple smaller parts.
comment:6 by , 16 years ago
@Alex: the problem with the length is the length relative to the surrounding text. What I was documenting is a complete edge-case and it takes up more space than the normal case, thus making it look like it might be really important to somebody reading that section.
Ah, this is a nice corner case. I really don't know whether this should be considered a bug or not! I only treat this as a bug so that it gets some attention before 1.0. This is really something for Malcolm to decide for himself.