Opened 5 years ago

Last modified 14 months ago

#17854 new New feature

Add database-specific checks for the maximum supported values of DecimalField max_digits, decimal_places

Reported by: anonymous Owned by: nobody
Component: Core (System checks) Version: master
Severity: Normal Keywords: DecimalField bug
Cc: Walter Doekes 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 Morales)

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 Taylor Mitchell 5 years ago.
Test illustrating behavior
test_ticket17854.2.patch (1.3 KB) - added by Taylor Mitchell 5 years ago.
Test illustrating problem

Download all attachments as: .zip

Change History (14)

comment:1 Changed 5 years ago by 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)

comment:2 in reply to:  1 ; Changed 5 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 5 years ago by anonymous

Component: UncategorizedDatabase 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 19 months ago by johnhomes (previous) (diff)

comment:4 Changed 5 years ago by anonymous

Summary: DecimalField problemDecimalField problem (please see a possible solution in comments)

comment:5 Changed 5 years ago by Ramiro Morales

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

comment:6 Changed 5 years ago by Ramiro Morales

Severity: Release blockerNormal

Changed 5 years ago by Taylor Mitchell

Attachment: test_ticket17854.patch added

Test illustrating behavior

comment:7 Changed 5 years ago by Taylor Mitchell

Triage Stage: UnreviewedAccepted

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

Version 2, edited 5 years ago by Taylor Mitchell (previous) (next) (diff)

Changed 5 years ago by Taylor Mitchell

Attachment: test_ticket17854.2.patch added

Test illustrating problem

comment:8 Changed 5 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 5 years ago by Ramiro Morales

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 4 years ago by Walter Doekes

Cc: Walter Doekes added

comment:11 Changed 16 months ago by Tim Graham

Summary: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backendProblem with DecimalField and big values of max_digits, decimal_places

comment:12 Changed 14 months ago by Tim Graham

Component: Database layer (models, ORM)Core (System checks)
Summary: Problem with DecimalField and big values of max_digits, decimal_placesAdd database-specific checks for the maximum supported values of DecimalField max_digits, decimal_places
Type: BugNew feature
Version: 1.3master

I think we could add database-specific checks (e.g. django/db/backends/mysql/validation.py) for the maximum values of max_digits, decimal_places supported by each database.

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