Opened 11 years ago

Closed 11 years ago

#18279 closed Bug (needsinfo)

Django ORM calculation of aggregate position is select queries

Reported by: deepak@… Owned by: nobody
Component: Database layer (models, ORM) Version: 1.4
Severity: Normal Keywords: orm
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: 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,

aggregate_start = len(self.query.extra_select.keys()) + len(
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 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.

Change History (1)

comment:1 Changed 11 years ago by Luke Plant

Resolution: needsinfo
Status: newclosed

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.

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