Changes between Initial Version and Version 1 of Ticket #36030, comment 24
- Timestamp:
- Nov 20, 2025, 6:56:49 AM (10 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #36030, comment 24
initial v1 52 52 Your point about Decimal(float_var) being a poor choice for controlling precision is absolutely correct in general, but here the main problem isn’t the number of decimal places encoded in the literal — it’s that: 53 53 54 the database no longer “knows” that one operand is a decimal/numeric type at all, so it defaults to truncating integer division, and 55 56 that loss of type information happens in some cases but not others, depending on how the constant is constructed and which backend is in use. 54 * the database no longer “knows” that one operand is a decimal/numeric type at all, so it defaults to truncating integer division, and 55 * that loss of type information happens in some cases but not others, depending on how the constant is constructed and which backend is in use. 57 56 58 57 So the behavior that feels “buggy” is: 59 58 60 Same ORM expression, different result across official backends. 61 62 Does this explanation help? 63 64 Same conceptual intent (“divide by a decimal constant”), but the database sees INT / INT in some cases because the decimal-ness of the constant wasn’t preserved in the generated SQL. 59 * Same ORM expression, different result across official backends. 60 * Same conceptual intent (“divide by a decimal constant”), but the database sees INT / INT in some cases because the decimal-ness of the constant wasn’t preserved in the generated SQL. 65 61 66 62 From a framework-user point of view, the ideal outcome would be: 67 63 68 For expressions like F("int_field") / Decimal(...) (and analogous arithmetic), Django consistently ensures that the database sees a NUMERIC/DECIMAL operand, so the operation is always done in decimal arithmetic; or 69 70 If that’s not feasible, the limitation and backend differences are clearly documented. 64 * For expressions like F("int_field") / Decimal(...) (and analogous arithmetic), Django consistently ensures that the database sees a NUMERIC/DECIMAL operand, so the operation is always done in decimal arithmetic; or 65 * If that’s not feasible, the limitation and backend differences are clearly documented. 71 66 72 67 I’m very much in favor of the ongoing work to address the SQLite discrepancy. I just want to make sure the underlying cross-backend consistency concern (integer vs decimal division when a Decimal constant is involved) doesn’t get lost in the focus on the construction of Decimal from floats or on SQLite alone. 68 69 Does this explanation help?