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

[Manuel Saelices]

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.

[Russell Keith-Magee]

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?

[Manuel Saelices]

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.

[Kenneth Arnold]

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

[Carl Meyer]

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.

[Ramiro Morales]

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.

[Ramiro Morales]

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.