Changes between Initial Version and Version 1 of Ticket #35077, comment 4


Ignore:
Timestamp:
Jan 1, 2024, 7:08:15 PM (10 months ago)
Author:
Simon Charette

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35077, comment 4

    initial v1  
    55> I would expect under or overflow exception to be propagated to the caller.
    66
    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).
     7It 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.
    88
    99The 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.
Back to Top