Django

Code

Ticket #4431 (closed: fixed)

Opened 1 year ago

Last modified 1 year ago

manage.py loaddata should have better error reporting

Reported by: bugs@almad.net Assigned to: dakrauth
Milestone: Component: Tools
Version: SVN Keywords: manage.py loaddata dumpdata
Cc: Triage Stage: Ready for checkin
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

4431.diff (3.0 kB) - added by dakrauth on 12/01/07 18:13:30.

Change History

05/30/07 08:03:33 changed by Simon G. <dev@simon.net.nz>

  • needs_better_patch changed.
  • stage changed from Unreviewed to Design decision needed.
  • needs_tests changed.
  • needs_docs changed.

05/30/07 16:37:17 changed by jacob

  • stage changed from Design decision needed to Accepted.

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

06/01/07 20:36:48 changed by russellm

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

07/12/07 09:47:24 changed by russellm

  • owner changed from adrian to russellm.

09/25/07 08:32:04 changed by Jonathan Ballet <jon@multani.info>

  • keywords changed from manage.py loaddata to manage.py loaddata dumpdata.

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.

12/01/07 15:27:50 changed by dakrauth

  • owner changed from nobody to dakrauth.

12/01/07 18:13:30 changed by dakrauth

  • attachment 4431.diff added.

12/01/07 18:17:42 changed by dakrauth

  • stage changed from Accepted to Ready 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.

12/02/07 13:50:39 changed by jacob

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

12/17/07 05:09:33 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

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

Add/Change #4431 (manage.py loaddata should have better error reporting)




Change Properties
Action