Opened 17 months ago

Closed 17 months ago

Last modified 14 months ago

#34706 closed Uncategorized (duplicate)

Aggregation on annotated field fails starting on Django 4.2.2, when the aggregation has the same name as the annotation

Reported by: Lorenzo Peña Owned by: nobody
Component: Uncategorized Version: 4.2
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

This would be the minimum reproducible example:

from django.db import models
from django.db.models import F, Sum


class House(models.Model):

    price = models.IntegerField()


House.objects.annotate(total=F("price")).aggregate(total=Sum("total"))

# ProgrammingError: column "total" does not exist
# SELECT SUM("total") AS "total" FROM "app_house"

This works in Django 4.2.1.

Change History (6)

comment:1 by Lorenzo Peña, 17 months ago

Summary: Aggregation on annotated field fails starting on Django 4.2.2Aggregation on annotated field fails starting on Django 4.2.2, when the aggregation has the same name as the annotation

comment:2 by Simon Charette, 17 months ago

Resolution: duplicate
Status: newclosed

Duplicate of #31679. This Django 4.2 feature had to be be reverted in Django 4.2.1 has it caused regressions in other areas.

comment:3 by Lorenzo Peña, 14 months ago

Good day everyone! I see this is still broken in Django 5.0a1. What is the expected course of action from our side?

in reply to:  3 comment:4 by Mariusz Felisiak, 14 months ago

Replying to Lorenzo Peña:

Good day everyone! I see this is still broken in Django 5.0a1. What is the expected course of action from our side?

You can prepare a patch for #31679.

comment:5 by Lorenzo Peña, 14 months ago

Marius, I apologize if I sounded demanding or challenging. Let me try again.

The behavior reported here started happening in the patch release 4.2.2. The code where it's breaking for me used to work properly in 4.2.0 and 4.2.1. I was expecting either a fix in the 4.2 series, or in the 5.0 series, or at least a resolution in the form of documentation. In my code I have the Django version pinned to 4.2.1. I would like to make a decision on whether to continue waiting, or changing my code to not use the same name in the annotation and the aggregation. When I asked what the "expected course of action from our side" was, I was referring to that.

I really wish I could do more to Django, but I lack the in-depth knowledge to do so. Unfortunately, preparing a patch is not a viable option for me. I can, however, change my own codebase so that it doesn't have the breaking behavior, which from your response I assume I should do.

Version 0, edited 14 months ago by Lorenzo Peña (next)

in reply to:  5 comment:6 by Mariusz Felisiak, 14 months ago

The behavior reported here started happening in the patch release 4.2.2. The code where it's breaking for me used to work properly in 4.2.0 and 4.2.1. I was expecting either a fix in the 4.2 series, or in the 5.0 series, or at least a resolution in the form of documentation. In my code I have the Django version pinned to 4.2.1. I would like to make a decision on whether to continue waiting, or changing my code to not use the same name in the annotation and the aggregation. When I asked what the "expected course of action from our side" was, I was referring to that.

Fix for #31679 was reverted in Django 4.2.2 because it introduces a regression. We cannot fix bugs by introducing different bugs. #31679 will not be fixed in Django 4.2.X.

I would like to make a decision on whether to continue waiting, or changing my code to not use the same name in the annotation and the aggregation.

I'd recommend changing your code.

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