#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 , 17 months ago
Summary: | Aggregation on annotated field fails starting on Django 4.2.2 → Aggregation on annotated field fails starting on Django 4.2.2, when the aggregation has the same name as the annotation |
---|
comment:2 by , 17 months ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
follow-up: 4 comment:3 by , 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?
comment:4 by , 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.
follow-up: 6 comment:5 by , 14 months ago
Mariusz, 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.
comment:6 by , 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.
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.