manage.py loaddata should have better error reporting

[bugs@…]

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.

[Jacob]

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

[Russell Keith-Magee]

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

[Jonathan Ballet <jon@…>]

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.

[David A Krauth]

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.

[Jacob]

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

[Malcolm Tredinnick]

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