Re: #7560 casting now breaks filters (ints, bools, floats) in get_db_prep_value
|Reported by:||magneto||Owned by:||nobody|
|Component:||Database layer (models, ORM)||Version:||master|
|Cc:||django@…||Triage Stage:||Design decision needed|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
The Changes in r8131 in django/db/models/fields/init.py
to get_db_prep_value for the 'Casted' Field types (Auto, Int, Bool, Decimal, Dates, etc) now really messes with the Filters
for instances, 'searching' where one wants to do a big 'Or' type statment
q = "Some unknown String" Obj.objects.filter(pk = q) | Obj.objects.filter(name = q) | Obj.objects.filter(other_field = q)
this will now throw a Value Error in the "pk = q" if the "q" is not an Int ... yes, technically it should be an int, but when build complex queries, with many parameters, 'type checking' everything, in the supposed non-typed language does seem strange.
this, to me is bad form, (for one, 'AutoField' need not just be an Int, but a binary hash or some other unique thing) ..
the data base (because the Query generator actually quotes the input argument) will certain not match non-ints,
i'd also imagine that 'bools' in some DBs can be '1/0, True/False, 'y/n', or just plain 'not 0'
Someone can correct me if i'm wrong, but i'm not sure of any DB today that will throw an error if one tries to match an int column to a string (id = "abc"), so why is this forced type checking here as well?
I do agree that on a "save" event one wants to validate the types, but on a "filter"?