Django ORM calculation of aggregate position is select queries

[deepak@…]

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.

[Luke Plant]

If we can't find a bug caused by this, with a test, we're not going to fix it. So I'm going to close as NEEDSINFO - particularly, the conditions under which this might cause a bug.