Re: manage.py loaddata fails to report error [was: Why does dumpdata, flush, loaddata cycle not result in same db content?]

[Russell Keith-Magee]

On Thu, Apr 16, 2009 at 11:30 AM, Phil Mocek
 wrote:
>
> On Thu, Apr 16, 2009 at 11:03:33AM +0800, Russell Keith-Magee wrote:
>> Loaddata doesn't take input from stdin - it loads files that are
>> specified on the command line.
>
> Thanks, Russell.
>
> I should have read the documentation for the loaddata command more
> closely, but this is quite counter-intuitive.  Can someone tell me
> what the rationale for this syntax is?

In my original response, I oversimplified a little. The rationale with
loaddata is that you're not actually specifying a filename. What
you're specifying is a label, and Django will discover multiple
fixtures using that label. By happy coincidence, a label can be a
filename, but filenames are a subset of all possible labels.

The classic example for loaddata is the initial data fixture. When you
run syncdb, Django loads the 'initial_data' fixture - that is, any
fixture, in any of the supported locations, in any supported format,
with the label "initial_data". This means every application in your
project can potentially provide an initial data fixture; some in XML,
some in JSON, some in YAML, and they will all be loaded automatically.

initial_data is a special case because of the relationship with
syncdb, but the same rules apply to any fixture - if you put a
collection of fixtures called 'bootstrap' around your project, you can
'loaddata bootstrap' and they will all be loaded.

The problem with loading a fixture from stdin is that you have no idea
what format that fixture is. Currently, fixture format is detected
from the filename extension; if fixture data comes from stdin, we
would need to either:
 1) Use file magic to work out what type of input was being provided
 2) Add a --format option so the input format could be explicitly specified.

Neither of these two options particularly appeals to me, but I am open
to be being convinced otherwise.

> The built-in usage help shows that the filename argument (called a
> fixture for reasons that I have not yet researched) is mandatory:
>
>    Usage: manage.py loaddata [options] fixture [fixture ...]
>
> However, manage.py does not report an error when a fixture is not
> specified:
>
>    $ ./manage.py loaddata
>    $ echo $?
>    0

The fact that no error message is raised for the 'you didn't provide
any arguments' case looks like a bug to me.This should be logged
as a new ticket so it isn't forgotten.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

manage.py loaddata fails to report error [was: Why does dumpdata, flush, loaddata cycle not result in same db content?]

[Phil Mocek]

On Thu, Apr 16, 2009 at 11:03:33AM +0800, Russell Keith-Magee wrote:
> Loaddata doesn't take input from stdin - it loads files that are
> specified on the command line.

Thanks, Russell.

I should have read the documentation for the loaddata command more
closely, but this is quite counter-intuitive.  Can someone tell me
what the rationale for this syntax is?

The built-in usage help shows that the filename argument (called a
fixture for reasons that I have not yet researched) is mandatory:

Usage: manage.py loaddata [options] fixture [fixture ...]

However, manage.py does not report an error when a fixture is not
specified:

$ ./manage.py loaddata 
$ echo $?
0

Only when I bump the verbosity up from 0 to 2 is an error
reported, and the return code still indicates success:

$ ./manage.py loaddata --verbosity=1 ; echo $?
0
$ ./manage.py loaddata --verbosity=2 ; echo $?
No fixtures found.
0

This is pretty bad unless there's a preferred method of loading
data in a non-interactive manner.


Possibly-relevant tickets found with a search of the Django Trac
(for "manage.py loaddata") include:

#6724 (loaddata w/ errors displays no warnings or error in output)
closed as duplicate of #4499 (integrity error silently failing with 
postgres and loaddata)

#4431 (manage.py loaddata should have better error reporting)
closed as fixed with r6936

#4371 (fixture loading fails silently in testcases)
closed as fixed with r7595

#10200 (loaddata command does not raise CommandError on errors)
new

-- 
Phil Mocek

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---