ORing with an empty Q() produces inconsistent results

[ris]

Using django 1.7.4, postgres 9.1.

Minimal testcase models.py:

from django.db import models

class ModelA ( models.Model ):
	pass

then:

>>> for i in xrange ( 1 , 5 ):
...     ModelA.objects.create ( pk = i )

>>> ModelA.objects.filter ( Q ( pk__in = () ) )
[]

correctly returning no results.

also

>>> ModelA.objects.filter ( Q ( pk__in = (1,2,) ) | Q () )
[<ModelA: 1>, <ModelA: 2>]

again, correct

however

>>> ModelA.objects.filter ( Q ( pk__in = () ) | Q () )
[<ModelA: 1>, <ModelA: 2>, <ModelA: 3>, <ModelA: 4>]

where I would have expected no instances to be returned.

The empty Q here has the effect of turning the pk__in into a no-op.

Interestingly, reformulating it as a (no-result-returning) subquery produces the expected result:

>>> ModelA.objects.filter ( Q ( pk__in = ModelA.objects.filter ( pk__isnull = True ) ) | Q () )
[]

I realize that OR'ing with an empty Q may not be something you're really supposed to do, but sometimes it does happen and this behaviour is quite unexpected.

Apologies if this is a duplicate but I was unable to find an existing ticket covering this.

[Anssi Kääriäinen]

ORin with an empty Q() is something we support. A common pattern is to do something like this:

condition = Q()
if foo:
    condition = condition | Q(foo=True)
if bar:
   condition = condition | Q(bar=True)
qs.filter(condition)

The empty Q() should not have any effect at all, whether ORed or ANDed into the query.

I confirmed the issue with a test available in ​https://github.com/akaariai/django/tree/ticket_24279.

As it happens, work done in ​https://github.com/django/django/pull/3779 fixes this issue (it changes the way empty Q() nodes are handled). It should be committed to master any minute now. I'm not sure if we need to fix this in 1.8 or 1.7. This isn't a serious bug (as in, things have worked like this for a long time, and users have survived it). This will also subtly change results of some queries, so I'm not too enthusiastic to backpatch this to released versions.

[Anssi Kääriäinen]

PR 3779 is now merged. I'll make a PR for this ticket to add the test. I think fixing this somewhat rare issue on master only should be OK.

[Tim Graham <timograham@…>]

In 20b74b10be069f6bae7555113a3781a66f3767a0:

Added a test for refs #24279

This issue was fixed in afe0bb7b13bb8dc4370f32225238012c873b0ee3.

[Дилян Палаузов]

Is this fixed or not? The last comment says it is, but the status is "new Bug".