Opened 7 years ago
Last modified 6 years ago
#29291 new Bug
Conditional expressions and ~Q queries — at Version 1
Description (last modified by ) ¶
I've run into an issue with conditional expressions using negated Q objects.
I would expect qs1
and qs2
to be equivalent in the following code:
class Application(models.Model): pass class Score(models.Model): application = models.ForeignKey(Application, on_delete=models.PROTECT) reviewed = models.BooleanField() a1 = Application.objects.create() Score.objects.create(reviewed=False, application=a1) Score.objects.create(reviewed=True, application=a1) a2 = Application.objects.create() qs1 = Application.objects.annotate( needs_review=Case( When(~Q(score__reviewed=True), then=V(True)), default=V(False), output_field=BooleanField() ) ).filter(needs_review=True) qs2 = Application.objects.filter( ~Q(score__reviewed=True) ) print(qs1) # <QuerySet [<Application: Application object (1)>, <Application: Application object (2)>]> print(qs2) # <QuerySet [<Application: Application object (2)>]> assert set(qs1) == set(qs2)
The identical ~Q
expression is behaving differently in the context of Case/When
and filter
. Am I completely missing something and this is expected behavior?
This is using Django 2.0.4.
According to the ticket's flags, the next step(s) to move this issue forward are:
- To provide a patch by sending a pull request. Claim the ticket when you start working so that someone else doesn't duplicate effort. Before sending a pull request, review your work against the patch review checklist. Check the "Has patch" flag on the ticket after sending a pull request and include a link to the pull request in the ticket comment when making that update. The usual format is:
[https://github.com/django/django/pull/#### PR]
.
Note:
See TracTickets
for help on using tickets.