#9209: ModelChoiceField fails when passed a non integer string
-------------------------------+--------------------------------------------
Reporter: Rozza | Owner: nobody
Status: new | Milestone:
Component: Forms | Version: 1.0
Resolution: | Keywords:
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------+--------------------------------------------
Comment (by kmtracey):
First, when creating a diff for patches please do so from the the top-
level trunk directory, not from within the django subdirectory, so it's
crystal clear where things go. Also, please don't name diff files with a
.py extension since trac then won't display them as diffs -- .diff is the
recommended suffix so trac can do its syntax highlighting thing. And
finally, tests that integrate with the existing test suite are more
helpful than standalone ones that have to then be fitted in somewhere.
That all said, unfortunately the 2nd approach doesn't work either, since
it requires that pk values be integers, which is not always true. One can
use explicit primary keys that are character fields, or floats, or ...
etc. so the field clean method can't require that they be integers. A way
to fix this (and deal with the fact that primary keys may be of varied
types, and the form input may fail to conform to that type), is to change
the `except: self.queryset.model.DoesNotExist` after the
`self.queryset.get` to a bare except. Not sure how acceptable that is as
a solution so I'll upload a patch with that and some integrated tests for
this case and see what others think.
I will note that I think the situation here is similar to the one the
admin code has to deal with in processing lookup parameters (see #9252).
I did think about narrowing the bare except used in that code in r9246,
but ultimately did not. The prospect of adding tests for the cross-
product of field types and possible inputs that could be supplied was more
than I wanted to take on...I did test enough random combinations to come
to the conclusion that there was not a single exception raised in the case
of input that failed to conform to type. For this ticket, we'd have to
add at least !ValueError and !ValidationError to the `except` to cover the
cases I tested ad-hoc for #9252...but there easily could be others I
didn't run across, so I'm tending to think the bare except is safer.
Unless there's some other approach I'm missing?
--
Ticket URL: <http://code.djangoproject.com/ticket/9209#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
