Opened 17 years ago

Closed 16 years ago

#4431 closed (fixed)

manage.py loaddata should have better error reporting

Reported by: bugs@… Owned by: David A Krauth
Component: Tools Version: dev
Severity: Keywords: manage.py loaddata dumpdata
Cc: Triage Stage: Ready for checkin
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When dumping database with

python manage.py --format=xml dumpdata > dump.xml

I'd like to migrate to another one and load data back. However, I perhaps have some inconsistency, so I got

 python manage.py loaddata dump.xml 
Loading 'dump' fixtures...
Installing xml fixture 'dump' from absolute path.
Problem installing fixture 'dump.xml': WikiObject matching query does not exist.

I have to fix it manually, however I have no idea which query failed and with FK I have to fix (or obect to delete etc.) (and yes, I have no idea when this inconsistency started).

loaddata should display on which object this query failed.

Attachments (1)

4431.diff (3.0 KB ) - added by David A Krauth 16 years ago.

Download all attachments as: .zip

Change History (10)

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

Triage Stage: UnreviewedDesign decision needed

comment:2 by Jacob, 17 years ago

Triage Stage: Design decision neededAccepted

A good way to handle this would be to add a --traceback option to manage.py which would dump the traceback if something fails. This would be consistent with the way some other tools written in Python do things (bzr, hg, others).

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

FYI - the underlying cause of this problem is described in ticket #4459. However, you are correct - the error reporting should be improved.

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

Owner: changed from Adrian Holovaty to Russell Keith-Magee

comment:5 by Jonathan Ballet <jon@…>, 16 years ago

Keywords: dumpdata added

The same problem occured when using dumpdata, if the database is inconsistent (differences between the models and the schema).

For example, consider a class A with a FK to class B. If the FK is removed from the database, and rows in table_A refers to id which are not in table_B, dumpdata will fail with a "B matching query does not exist."

This is not a bug in dumpdata, but if it reported errors more accurately, it might be easier to debug.

comment:6 by David A Krauth, 16 years ago

Owner: changed from nobody to David A Krauth

by David A Krauth, 16 years ago

Attachment: 4431.diff added

comment:7 by David A Krauth, 16 years ago

Triage Stage: AcceptedReady for checkin

Added --traceback option at a the topmost Command level. Where appropriate, exceptions should be allowed to propagate. End users can then run pdb to inspect the exception stack frame.

comment:8 by Jacob, 16 years ago

We should double-check that this applies to #2947 as well.

comment:9 by Malcolm Tredinnick, 16 years ago

Resolution: fixed
Status: newclosed

(In [6936]) Fixed #4431 -- Added a --traceback option for dumpdata and loaddata (which
shows how it can be used for other commands as well). Thanks, dakrauth.

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