Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#17796 closed Bug (fixed)

Aggregating an IntegerField returns Decimal from MySQL

Reported by: adsva Owned by: nobody
Component: Uncategorized Version: dev
Severity: Normal Keywords: orm, aggregate
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

>>> MyModel.objects.get(pk=1).my_int_field
>>> 581L
>>> MyModel.objects.filter(pk=1).aggregate(Sum('my_int_field'))
>>> {'my_int_field__sum': Decimal('581')}

The aggregate used to return an integer until recently.

It looks like changeset:17588 added a convert_values-method to the DataBaseOperations class for the MySQL backend, but since it only handles Boolean conversions, it should probably call the parent's convert_values if it's not a boolean?

Attachments (1)

aggtype.patch (649 bytes ) - added by adsva 12 years ago.

Download all attachments as: .zip

Change History (3)

by adsva, 12 years ago

Attachment: aggtype.patch added

comment:1 by Ramiro Morales, 12 years ago

Resolution: fixed
Status: newclosed

In [17603]:

Fixed #17796 -- Rolled back [17588] because the fix for the original relatively
corner case (boolean fields under MySQL spatial backend) had a wider scope with
potentially unintended consequences affecting the main MySQL backend and the
required changes wouldn't be appropiate at this point of the 1.4 development
cycle.

Refs #15169.

in reply to:  description comment:2 by Ramiro Morales, 12 years ago

Replying to adsva:

It looks like changeset:17588 added a convert_values-method to the DataBaseOperations class for the MySQL backend, but since it only handles Boolean conversions, it should probably call the parent's convert_values if it's not a boolean?

Yes I had seen the test failures that started to show with that commit under Python 2.5 and 2.6 against MySQL and had been able to reproduce them with Python 2.6 (original work and testing on the fix for #15169 had been done only with 2.7).

I tried to fix these problems following the same strategy you suggest (falling back the parent method) but it introduces its own problems, in particular the fallback to return float(value) causes an inmediate error when processing CHAR-based fields as can be seen when trying to run the test suite. This seems to indicate convert_values() is currently being called from some but not all of the code paths in which data flows from the DB to the model layer, at least in the MySQL case.

I decided to simply undo the change until this problem can be analized with more time and without the risk of breaking things at this point of the 1.4 release cycle.

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