Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#16026 closed New feature (fixed)

Inform user which object triggered error in loaddata

Reported by: gabrielhurley Owned by: gabrielhurley
Component: Core (Management commands) Version: 1.3
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

When the loaddata command saves objects it is entirely possible for the database to raise an exception, which is all well and good except for the fact that the standard IntegrityError and DatabaseError messages don't mention which object raised the exception. This can make debugging a fixture with dozens, hundreds or thousands of objects in it nearly impossible.

So I've got a patch here which adds one extra line of output notifying the user of which object (and which DB) raised the error before re-raising the exception.

Attachments (2)

loaddata_error.diff (3.5 KB) - added by gabrielhurley 4 years ago.
Full patch with change, test, and additional intentionally invalid fixture.
16026_loaddata_error.diff (3.5 KB) - added by gabrielhurley 4 years ago.
Updated ticket as per Jacob's feedback

Download all attachments as: .zip

Change History (9)

comment:1 Changed 4 years ago by PaulM

  • Triage Stage changed from Unreviewed to Ready for checkin

This looks good to me. I'm marking it as rfc. This should help reduce the number of support requests we have to deal with.

comment:2 Changed 4 years ago by lukeplant

  • Needs tests set
  • Triage Stage changed from Ready for checkin to Accepted

There doesn't seem to be a reason to skip tests - see modeltests/fixtures/tests.py - so I'm changing the flags accordingly.

comment:3 Changed 4 years ago by gabrielhurley

  • Needs tests unset
  • Triage Stage changed from Accepted to Ready for checkin
  • UI/UX unset

Improved the patch to return revised message as the exception string, which is vastly preferable. Unit test now included. Bumping back to RFC having fixed the aforementioned problem.

Changed 4 years ago by gabrielhurley

Full patch with change, test, and additional intentionally invalid fixture.

comment:4 Changed 4 years ago by jacob

  • Easy pickings set
  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

This isn't quite RFC: the error message is different on different db engines (e.g. "null value in column "headline" violates not-null constraint" vs "fixtures_article.headline may not be NULL"), so the test fails. Other than that this is perfect; please mark back to RFC when that's fixed.

Changed 4 years ago by gabrielhurley

Updated ticket as per Jacob's feedback

comment:5 Changed 4 years ago by gabrielhurley

  • Patch needs improvement unset
  • Triage Stage changed from Accepted to Ready for checkin

Changed to using an assertRegexpMatches for the error string rather than an assertEqual to support differing database error messages. Should be all set now.

comment:6 Changed 4 years ago by jacob

#10200 was a duplicate.

comment:7 Changed 4 years ago by PaulM

  • Resolution set to fixed
  • Status changed from new to closed

In [16873]:

Fixed #16026 -- loaddata now identifies which object triggered an error.

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