Opened 17 years ago

Closed 17 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: 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)

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

Download all attachments as: .zip

Change History (3)

by stvsmth@…, 17 years ago

Attachment: patch added

patch for ticket 5784

comment:1 by Simon G <dev@…>, 17 years ago

Patch needs improvement: set
Triage Stage: UnreviewedAccepted

comment:2 by Russell Keith-Magee, 17 years ago

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

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