Changes between Initial Version and Version 1 of Ticket #35077, comment 4
- Timestamp:
- Jan 1, 2024, 7:08:15 PM (10 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35077, comment 4
initial v1 5 5 > I would expect under or overflow exception to be propagated to the caller. 6 6 7 It is propagated if you validate the data before hand through validation errors. If you pass invalid data to a queryset lookup I would say that you venture into undefined behaviour territory and changing it to raise an exception would be backward compatible. For example, think of all `IntegerField` (and it's derivative such as `AutoField` and `PositiveIntegerField`) which would result in an unhandled exception when doing `SomeModel.objects.get(pk=pk)` and `pk` is used controlled (e.g. passed through an url pattern) .7 It is propagated if you validate the data before hand through validation errors. If you pass invalid data to a queryset lookup I would say that you venture into undefined behaviour territory and changing it to raise an exception would be backward compatible. For example, think of all `IntegerField` (and it's derivative such as `AutoField` and `PositiveIntegerField`) which would result in an unhandled exception when doing `SomeModel.objects.get(pk=pk)` and `pk` is used controlled (e.g. passed through an url pattern) and thus an overflowing value can be provided. 8 8 9 9 The one premise that the ORM and its query generation machinery must be able to assume is that it has a proper Python level schema mapping to the tables it's generating SQL for. It you break this premise you should expect the unexpected.