#16026 closed New feature (fixed)
Inform user which object triggered error in loaddata
| Reported by: | Gabriel Hurley | Owned by: | Gabriel Hurley |
|---|---|---|---|
| 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)
Change History (9)
comment:1 Changed 13 years ago by
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
comment:2 Changed 13 years ago by
| Needs tests: | set |
|---|---|
| Triage Stage: | Ready for checkin → 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 12 years ago by
| Needs tests: | unset |
|---|---|
| Triage Stage: | Accepted → 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 12 years ago by
| Attachment: | loaddata_error.diff added |
|---|
Full patch with change, test, and additional intentionally invalid fixture.
comment:4 Changed 12 years ago by
| Easy pickings: | set |
|---|---|
| Patch needs improvement: | set |
| Triage Stage: | Ready for checkin → 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 12 years ago by
| Attachment: | 16026_loaddata_error.diff added |
|---|
Updated ticket as per Jacob's feedback
comment:5 Changed 12 years ago by
| Patch needs improvement: | unset |
|---|---|
| Triage Stage: | Accepted → 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.
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.