Changes between Initial Version and Version 1 of Ticket #36484
- Timestamp:
- Jun 29, 2025, 6:47:04 AM (2 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #36484 – Description
initial v1 1 = =Overview1 = Overview 2 2 In Django 5.0 the behaviour for arithmetic that overflows an integer column changed: a filter that would overflow now always returns an empty QuerySet instead of being transparently cast to a wider integer type (the historical behaviour on most back-ends). While this keeps runtime semantics simple, it makes migrations from Django 4.x harder to verify—tests may “pass” yet silently return fewer (or zero) rows. It is also difficult for developers on 5.x to notice when an overflow is happening because the condition is swallowed inside the ORM. 3 3 (see: https://docs.djangoproject.com/en/5.2/releases/5.0/#:~:text=Filtering%20querysets%20against%20overflowing%20integer%20values%20now%20always%20returns%20an%20empty%20queryset.%20As%20a%20consequence%2C%20you%20may%20need%20to%20use%20ExpressionWrapper()%20to%20explicitly%20wrap%20arithmetic%20against%20integer%20fields%20in%20such%20cases) … … 5 5 To improve debuggability and give teams a migration aid, I propose an opt-in setting that raises a specific exception the moment an overflow is detected. 6 6 7 = =Proposal7 = Proposal 8 8 9 == =Add new parameter.9 == Add new parameter. 10 10 {{{ 11 11 # settings.py … … 13 13 }}} 14 14 15 == =Implementation sketch15 == Implementation sketch 16 16 17 17 * Add new exception … … 41 41 The setting defaults to False, so existing applications keep the current silent-empty semantics unless they explicitly enable strict mode. 42 42 43 == =Benefits43 == Benefits 44 44 45 45 * Safe migrations – Projects upgrading from 4.x can enable the flag in CI to surface every place where arithmetic now truncates results.