Opened 12 years ago

Last modified 8 years 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: dev
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 12 years ago.
Test illustrating behavior
test_ticket17854.2.patch (1.3 KB ) - added by Taylor Mitchell 12 years ago.
Test illustrating problem

Download all attachments as: .zip

Change History (14)

comment:1 by anonymous, 12 years ago

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)

in reply to:  1 ; comment:2 by anonymous, 12 years ago

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)

in reply to:  2 comment:3 by anonymous, 12 years ago

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 9 years ago by johnhomes (previous) (diff)

comment:4 by anonymous, 12 years ago

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

comment:5 by Ramiro Morales, 12 years ago

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 by Ramiro Morales, 12 years ago

Severity: Release blockerNormal

by Taylor Mitchell, 12 years ago

Attachment: test_ticket17854.patch added

Test illustrating behavior

comment:7 by Taylor Mitchell, 12 years ago

Triage Stage: UnreviewedAccepted

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

Last edited 12 years ago by Taylor Mitchell (previous) (diff)

by Taylor Mitchell, 12 years ago

Attachment: test_ticket17854.2.patch added

Test illustrating problem

comment:8 by anonymous, 12 years ago

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 by Ramiro Morales, 12 years ago

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

Cc: Walter Doekes added

comment:11 by Tim Graham, 9 years ago

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 by Tim Graham, 8 years ago

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