id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
18279	Django ORM calculation of aggregate position is select queries	deepak@…	nobody	"Hello,
I believe I have discovered this bug in django 1.4 ORM. I am not familiar enough with the ORM to write a patch. Here, https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L784

{{{
aggregate_start = len(self.query.extra_select.keys()) + len(self.query.select)
aggregate_end = aggregate_start + len(self.query.aggregate_select)
row = tuple(row[:aggregate_start]) + tuple([
                        self.query.resolve_aggregate(value, aggregate, self.connection)
                        for (alias, aggregate), value
                        in zip(self.query.aggregate_select.items(), row[aggregate_start:aggregate_end])
                    ]) + tuple(row[aggregate_end:])

}}}
I believe aggregate_start should be calculated using the number of non-deferred fields rather than the length of query.select which is equal to the all the fields in the model.  During some debugging I found that aggregate_start was being calculated way past the number of elements in the db returned row. Strangely, the bug has no side-effects because resolve_aggregate is never called since it operates on an empty list.

Lastly, I think this is a bug but I am not sure why this has no side-effects."	Bug	closed	Database layer (models, ORM)	1.4	Normal	needsinfo	orm		Unreviewed	0	0	0	0	0	0