Django ORM calculation of aggregate position is select queries
|Reported by:||deepak@…||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||1.4|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
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.