Opened 12 years ago

Closed 12 years ago

#5784 closed (wontfix)

Include field name that causes validation error in CharField.to_python

Reported by: stvsmth@… Owned by: nobody
Component: Database layer (models, ORM) Version: master
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


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)

patch (635 bytes) - added by stvsmth@… 12 years ago.
patch for ticket 5784

Download all attachments as: .zip

Change History (3)

Changed 12 years ago by stvsmth@…

Attachment: patch added

patch for ticket 5784

comment:1 Changed 12 years ago by Simon G <dev@…>

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

comment:2 Changed 12 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

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 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.

Note: See TracTickets for help on using tickets.
Back to Top