Code

Opened 7 years ago

Closed 6 years ago

#4431 closed (fixed)

manage.py loaddata should have better error reporting

Reported by: bugs@… Owned by: dakrauth
Component: Tools Version: master
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: UI/UX:

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 dakrauth 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

comment:2 Changed 7 years ago by jacob

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

comment:3 Changed 7 years ago by russellm

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

comment:4 Changed 7 years ago by russellm

  • Owner changed from adrian to russellm

comment:5 Changed 7 years ago by Jonathan Ballet <jon@…>

  • 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 Changed 6 years ago by dakrauth

  • Owner changed from nobody to dakrauth

Changed 6 years ago by dakrauth

comment:7 Changed 6 years ago by dakrauth

  • Triage 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.

comment:8 Changed 6 years ago by jacob

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

comment:9 Changed 6 years ago by mtredinnick

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

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

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.