Opened 3 years ago

Last modified 4 weeks ago

#17854 new Bug

Problem with DecimalField and big values of max_digits, decimal_places

Reported by: anonymous Owned by: nobody
Component: Database layer (models, ORM) Version: 1.3
Severity: Normal Keywords: DecimalField bug
Cc: wdoekes Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by ramiro)

For a model field created as

models.DecimalField(max_digits = 200, decimal_places = 100, blank = False, null = False)

While using admin interface to insert a record involving such a DecimalField, the format changes (loss of precision and it uses scientific notation (even in the database)) (Please note - it works properly for low precision values (example - .987654321001234) - but for larger precision values (probably 15 decimal_places or more) it results in loss of precision)

  • django version 1.3.1 and 1.4c1 (don't know about older versions);
  • python 2.6.6;
  • linux;

Attachments (2)

test_ticket17854.patch (1.4 KB) - added by tmitchell 3 years ago.
Test illustrating behavior
test_ticket17854.2.patch (1.3 KB) - added by tmitchell 3 years ago.
Test illustrating problem

Download all attachments as: .zip

Change History (13)

comment:1 follow-up: Changed 3 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

The database is sqlite3

The database field (for sqlite3) is 'decimal' (when the field type in the database is changed to say varchar(n) where n > (values to be stored (in this case probably 202)) - everything works perfectly.

The problem seems to be that django emits the column type as decimal for sqlite3 (for other databases this problem is untested) instead of varchar(max_length + probably 2)

comment:2 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by anonymous

Replying to anonymous:

The database is sqlite3

The database field (for sqlite3) is 'decimal' (when the field type in the database is changed to say varchar(n) where n > (values to be stored (in this case probably 202)) - everything works perfectly.

The problem seems to be that django emits the column type as decimal for sqlite3 (for other databases this problem is untested) instead of varchar(max_length + probably 2)

typo resolution for the above line == instead of varchar(max_digits + probably 2)

comment:3 in reply to: ↑ 2 Changed 3 years ago by anonymous

  • Component changed from Uncategorized to Database layer (models, ORM)

Replying to anonymous:

Replying to anonymous:

The database is sqlite3

The database field (for sqlite3) is 'decimal' (when the field type in the database is changed to say varchar(n) where n > (values to be stored (in this case probably 202)) - everything works perfectly.

The problem seems to be that django emits the column type as decimal for sqlite3 (for other databases this problem is untested) instead of varchar(max_length + probably 2)

typo resolution for the above line == instead of varchar(max_digits + probably 2)

if does not create any side effect(s) a change to this might be the solution === django/db/backends/sqlite3/creation.py

also similar change to respective backends might be the solution (in case a database has limits (unlike python Decimals) on the scale, precision for its corresponding column type)
http://lockerdome.com/blog

Last edited 4 months ago by johnhomes (previous) (diff)

comment:4 Changed 3 years ago by anonymous

  • Summary changed from DecimalField problem to DecimalField problem (please see a possible solution in comments)

comment:5 Changed 3 years ago by ramiro

  • Summary changed from DecimalField problem (please see a possible solution in comments) to Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

comment:6 Changed 3 years ago by ramiro

  • Severity changed from Release blocker to Normal

Changed 3 years ago by tmitchell

Test illustrating behavior

comment:7 Changed 3 years ago by tmitchell

  • Triage Stage changed from Unreviewed to Accepted

This is not specific to the admin, as the attached test shows. Test passes under postgres and mysql but fails under sqlite3.

Last edited 3 years ago by tmitchell (previous) (diff)

Changed 3 years ago by tmitchell

Test illustrating problem

comment:8 Changed 3 years ago by anonymous

This problem exists for postgres and mysql too (along with sqlite3).

for postgres - limit is up to 131072 digits before the decimal point; up to 16383 digits after the decimal point (from postgres website - http://www.postgresql.org/docs/9.1/static/datatype-numeric.html#DATATYPE-NUMERIC-TABLE)

similarly docs on the mysql site mention that a decimal field has a limit of 65 decimal places (but I do not know anything else as I haven't used mysql)

comment:9 Changed 3 years ago by ramiro

  • Description modified (diff)

Would be acceptable to "fix" this by documenting the limitations of the three database engine/adaptors in the DB notes document?

comment:10 Changed 3 years ago by wdoekes

  • Cc wdoekes added

comment:11 Changed 4 weeks ago by timgraham

  • Summary changed from Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend to Problem with DecimalField and big values of max_digits, decimal_places
Note: See TracTickets for help on using tickets.
Back to Top