Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#8025 closed (invalid)

Failed when lookups that span relationships with __isnull.

Reported by: bear330 Owned by: nobody
Component: Core (Other) Version: master
Severity: Keywords: isnull, span
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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 Changed 8 years ago by Michael Radziej

milestone: 1.01.0 beta
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

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.

comment:2 Changed 8 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

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 Changed 8 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: closedreopened

comment:4 Changed 8 years ago by Malcolm Tredinnick

Resolution: invalid
Status: reopenedclosed

comment:5 Changed 8 years ago by Alex Gaynor

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 Changed 8 years ago by Malcolm Tredinnick

@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.

comment:7 Changed 5 years ago by Jacob

milestone: 1.0 beta

Milestone 1.0 beta deleted

Note: See TracTickets for help on using tickets.
Back to Top