Opened 20 months ago

Last modified 20 months ago

#26434 new Bug

Inconsistent results of QuerySet count() method using PostgreSQL backend prior and post the QuerySet evaluation

Reported by: kamandol Owned by: nobody
Component: Database layer (models, ORM) Version: 1.9
Severity: Normal Keywords: postgresql queryset count annotate aggreagate order_by
Cc: github@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Using a PostgreSQL backend database, in some cases with QuerySets involving annotations, values or values_list and ordering(order_by) clauses the resulting QuerySet count() method fails to predict the real row result unless that QuerySet is evaluated.

For instance:

q = BundleVersion.objects.order_by('-id').values_list("port__id", "asset_bundle__id").annotate(max=models.Max("id"))

This QuerySet using PostgreSQL would, in fact, group the results by BundleVersion.id instead of the tuple ("port__id", "asset_bundle__id") due to the order_by clause using a column not in the values_list. This is a documented behavior.

The problem is that if q is not evaluated yet, calling q.count() will return an amount of rows as if the grouping was done on the tuple ("port__id", "asset_bundle__id"). After evaluating q, or calling len(q), the result of q.count() will be the expected, as if the grouping was done using 'BundleVersion.id'.

Change History (8)

comment:1 Changed 20 months ago by Tim Graham

Could you provide a test for Django's test suite in tests/queries/tests.py that demonstrates the issue?

comment:2 in reply to:  1 Changed 20 months ago by kamandol

Replying to timgraham:

Could you provide a test for Django's test suite in tests/queries/tests.py that demonstrates the issue?

Here is the commit with the demonstration:

https://github.com/sp-ricard-valverde/django/commit/c50afafdb02880e4c941c2a72a215bee80de3aed

comment:3 Changed 20 months ago by Iacopo Spalletti

Tests looks legitimate, but I don't get this one https://github.com/sp-ricard-valverde/django/commit/c50afafdb02880e4c941c2a72a215bee80de3aed#diff-ce9b52a66d03e851a9828377263dc04bR3864 ; or rather I don't get why is labeled as 'OK' as it the concatenation of the previous ones

comment:4 Changed 20 months ago by Iacopo Spalletti

Cc: github@… added

comment:5 in reply to:  3 Changed 20 months ago by kamandol

Replying to yakky:

Tests looks legitimate, but I don't get this one https://github.com/sp-ricard-valverde/django/commit/c50afafdb02880e4c941c2a72a215bee80de3aed#diff-ce9b52a66d03e851a9828377263dc04bR3864 ; or rather I don't get why is labeled as 'OK' as it the concatenation of the previous ones

Sorry, my bad, it's a bad choice for a test title. What it demonstrates is that the second assert in that test is successful even though a new QuerySet is built and, according to the other failed tests it should fail too.

comment:6 Changed 20 months ago by kamandol

Last edited 20 months ago by kamandol (previous) (diff)

comment:7 Changed 20 months ago by Tim Graham

Triage Stage: UnreviewedAccepted

If you could put the tests on a branch of you fork other than "master" that seems a bit safer. There is probably no need for skipUnlessDBEngine - is there a reason the queries shouldn't also work on other databases? Anyway, the usual way to skip tests is based on database features.

comment:8 Changed 20 months ago by kamandol

I will change the branch as requested.

You're right, the faulty behavior was detected on PostgreSQL, but on MySQL worked correctly so the test should pass. Could not test other db engines though. I will remove that extra piece of code.

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