Code

Opened 6 years ago

Closed 6 years ago

Last modified 3 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.

Attachments (0)

Change History (7)

comment:1 Changed 6 years ago by mir

  • milestone changed from 1.0 to 1.0 beta
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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 6 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to 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 Changed 6 years ago by mtredinnick

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:4 Changed 6 years ago by mtredinnick

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:5 Changed 6 years ago by Alex

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 6 years ago by mtredinnick

@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 3 years ago by jacob

  • milestone 1.0 beta deleted

Milestone 1.0 beta deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.