Code

Opened 7 years ago

Closed 6 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: UI/UX:

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@… 7 years ago.
patch for ticket 5784

Download all attachments as: .zip

Change History (3)

Changed 7 years ago by stvsmth@…

patch for ticket 5784

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

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement set
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 6 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to 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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.