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)

Change History (16)

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)

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)

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)