Changes between Version 37 and Version 41 of Ticket #36030
- Timestamp:
- Nov 25, 2025, 6:56:58 AM (5 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #36030
- Property Status new → assigned
- Property Summary SQLite backend: division with Decimal("x.0") operand and integer operand fails to preserve precision → SQLite backend: division with Decimal("x.0") operand discards fractional portion of result
- Property Needs tests set
- Property Owner set to
- Property Keywords sqlite added
-
Ticket #36030 – Description
v37 v41 1 1 == Expected Behavior == 2 When division is performed in Django, and at least one of the operands is a `decimal.Decimal` value created using the string constructor with at least one digit following the decimal point (for example, `Decimal("3.0")`), the precision of the result should be preserved. For example, `2 / Decimal("3.0")` should produce a value close to `0.6667`.2 When division is performed in Django, and at least one of the operands is a `decimal.Decimal` value created using the string constructor with at least one digit following the decimal point (for example, `Decimal("3.0")`), the fractional portion of the result should be retained. For example, `2 / Decimal("3.0")` should produce a value close to `0.6667`. 3 3 4 4 == Observed Behavior == 5 When such a division is performed using the SQLite backend and one of the operands is an integer, integer ("floor") division is performed unless the decimal value has a non-zero fractional part. For example, `2 / Decimal("3.1")` produces `0.64516129032258064516`, but `2 / Decimal("3.0")` produces `0`.5 When such a division is performed using the SQLite backend, integer ("floor") division is performed unless the decimal value has a non-zero fractional part. For example, `2 / Decimal("3.1")` produces `0.64516129032258064516`, but `2 / Decimal("3.0")` produces `0`. 6 6 7 7 == Repro Case == … … 34 34 cursor.execute(f"SELECT {sql}", params) 35 35 result = cursor.fetchone()[0] 36 print("result:", result). # prints036 print("result:", result). # -> result: 0 37 37 }}} 38 38 39 39 == Notes == 40 Th e original ticketreported that division using PostgreSQL as the backend did not consistently preserve precision when the denominator was a `Decimal` value. Further investigation confirmed that the same problem arises with SQLite, and that the inconsistent behavior is observed whether the `Decimal` operand is the numerator or the denominator. Testing showed that the other three officially supported database backends all preserve decimal precision in much the same way as native Python division mixing integer and decimal operands.40 This ticket originally reported that division using PostgreSQL as the backend did not consistently preserve precision when the denominator was a `Decimal` value. Further investigation confirmed that the same problem arises with SQLite, and that the inconsistent behavior is observed whether the `Decimal` operand is the numerator or the denominator. Testing showed that the other three officially supported database backends all preserve decimal precision in much the same way as native Python division mixing integer and decimal operands. 41 41 42 It has been decided that Django does not need to enforce consistent division behavior across all backends, as long as there is a way to force preservation of precision. With PostgreSQL, precision is preserved if the `Decimal` value is created with the string constructor and includes at least one digit after the decimal point (e.g., `Decimal("3.0")`). With SQLite, even `Decimal("3.0")` fails to preserve precision. Therefore, the scope of this ticket has been narrowed to address only the behavior of the SQLite driver. 42 It has been decided that Django does not need to enforce consistent division behavior across all backends, as long as there is a way to force preservation of the fractional portion of the result. With PostgreSQL, this is achieved if the `Decimal` value is created with the string constructor and includes at least one digit after the decimal point (e.g., `Decimal("3.0")`). With SQLite, even `Decimal("3.0")` fails to preserve the fractional portion of the result of the division operation. Therefore, the scope of this ticket has been narrowed to address only the behavior of the SQLite driver. 43 44 Note that the [https://docs.djangoproject.com/en/5.2/ref/databases/#sqlite-decimal-handling Django documentation for decimal handling using the SQLite backend] says that for this backend "Decimal values are internally converted to the `REAL` data type." 43 45 44 46 It was further decided that the user documentation should ''not'' describe the remaining inconsistencies between backends.