Opened 7 years ago

Closed 3 years ago

#7043 closed Bug (fixed)

Bad verbosity in loaddata command when fixtures location passed by param baddly

Reported by: msaelices Owned by: msaelices
Component: Core (Management commands) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Look, for example this execution:

 ~$ ./manage.py loaddata something_wrong_but_developer_doesnt_know.xml
 ~$ <-- no error message

But in [source:django/trunk/django/core/management/commands/loaddata.py loaddata.py] there is this code fragment:

   if object_count == 0:
       if verbosity >= 2:
           print "No fixtures found."

I think maybe it could be better to remove the verbosity condition.

Attachments (1)

loaddata.diff (618 bytes) - added by msaelices 7 years ago.

Download all attachments as: .zip

Change History (10)

Changed 7 years ago by msaelices

comment:1 Changed 7 years ago by msaelices

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Status changed from new to assigned

comment:2 follow-up: Changed 7 years ago by russellm

I'm not neccessarily disagreeing, but why do you think the verbosity should be removed? There is a reasonable argument for having the message the way it is - with normal verbosity, you get output only if a fixture is loaded, so it's easy to integrate with a shell script to determine if data was actually loaded. What is your reasoning for making the 'no fixtures' error compulsory?

comment:3 in reply to: ↑ 2 Changed 7 years ago by msaelices

Replying to russellm:

I'm not neccessarily disagreeing, but why do you think the verbosity should be removed? There is a reasonable argument for having the message the way it is - with normal verbosity, you get output only if a fixture is loaded, so it's easy to integrate with a shell script to determine if data was actually loaded. What is your reasoning for making the 'no fixtures' error compulsory?

I think will be useful for developers. Myself was trying to loaddata, but docs not explain if fixtures location is a path to an xml, or if is an application name or whatever. The problem is that you put an application name, and you don't know if fixtures are successfully loaded. Others commands, like dumpdata, fails if application is not found.

comment:4 Changed 7 years ago by kcarnold

+1 on this, since it just bit me again (I've used fixtures before, I just forgot to give it a .json extension). It's very surprising not to get an error.

If a script wants to check if data was actually loaded, that's what return values ($?) are for.

comment:5 Changed 7 years ago by Simon Greenhill

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 4 years ago by lukeplant

  • Severity set to Normal
  • Type set to Bug

comment:7 Changed 4 years ago by carljm

  • Easy pickings unset
  • Triage Stage changed from Design decision needed to Accepted
  • UI/UX unset

This is a real problem. If anything, the accepted pattern for command-line utilities is to be silent on success, noisy on failure (see, for example, rules 11 and 12 at http://www.faqs.org/docs/artu/ch01s06.html ). Silence on failure by default is bad.

comment:8 Changed 3 years ago by ramiro

Actually, many things have changed since this was reported four years ago.

Particularly, r13612 introduced a check that aborts the execution of the loaddata command when the no objects are found in al least one of the fixtures. This means the if fixture_object_count == 0: check (such is the name of the variable now, it contains the number of all objects found in all fixtures) is never reached.

The fix would be then to simply remove the dead code that performs this check.

comment:9 Changed 3 years ago by ramiro

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

In [17051]:

Enhanced loaddata error message printed when no DB fixture is provided.

Fixes #7043 by fixing the last code path where a misleading 'No fixtures found.' error message was being shown.

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