Opened 17 years ago
Closed 17 years ago
#5784 closed (wontfix)
Include field name that causes validation error in CharField.to_python
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | initial_data syncdb CharField | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
When importing using loaddata (in this case via fixtures/initial_data.json) an attempt to import null data into a field that doesn't allow null data has the unhelpful message:
Problem installing fixture '[snip]/initial_data.json': [u'This field cannot be null.']
When initial_data has is importing to lots of models/fields it would helpful to know which field is causing the problem:
Problem installing fixture '[snip]/initial_data.json': [u"The field 'split' cannot be null."]
Trivial patch included ... I'm new to Django, so it's unclear to me how to snag model name as well( "Model.Field cannot be null" ). It is also unclear to me whether this message would be silly when raised in other areas of the application.
Attachments (1)
Change History (3)
by , 17 years ago
comment:1 by , 17 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The error message altered by this patch isn't just a serialization/fixtures error - it is used by other subsystems.
In addition, there could be thousands of Model instances in a fixture, each of which will have a value for 'field'. Saying "Model.field cannot be none" won't help you find which Model.field instance in your fixture is the cause of the error. #6397 is a better proposal for improving error messages (although the implementation suggested there is not feasible).
On an administrative note, a complete patch should be generated against the root of the source tree - there are many init.py files in Django, and the patch you provided doesn't provide any context to say which file has been modified. A good patch will also include a test that validates the behaviour that has been modified.
patch for ticket 5784