Opened 15 years ago
Last modified 12 years ago
#13680 new Cleanup/optimization
loaddata should issue a warning when attempting to load data using an unknown serialization format even when it is unspecified
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Core (Serialization) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
"loaddata" will issue a warning when you specify the filename and extension of the fixtures (in an unknown format) you want to load as seen in the following example:
./manage.py loaddata myapp/fixtures/initial_data.yaml Problem installing fixture 'myapp/fixtures/initial_data': yaml is not a known serialization format.
"loaddata" has a less helpful message when you attempt to load data in an unknown format without specifying the file extension (the way syncdb does):
./manage.py loaddata myapp/fixtures/initial_data No fixtures found.
When the file myapp/fixtures/initial_data.yaml exists, and pyyaml is not installed, the warning message should be the same whether or not you specify the file extension. I'd argue that anyone attempting to load database fixtures by name (sans extension) when a file exists with the same name would want to see this kind of warning. Some applications rely on initial_data fixtures and any user who issues ./manage syncdb and expects initial_data to load automatically could be frustrated if they fail to notice the 'No fixtures found' message. A warning is more appropriate in this instance.
Change History (6)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 15 years ago
comment:3 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Cleanup/optimization |
comment:6 by , 12 years ago
Component: | Core (Other) → Core (Serialization) |
---|
I took a look at how loaddata processes fixtures and it appears that it builds a list of every possible combination of serialization and compression format then checks the filesystem for each one.
In order to solve this issue, we'll need to either have a secondary filesystem search for files that start with the specified fixture_labels, or we'll need to change the way loaddata works by first examining the filesystem for matches and then determining if suitable compression/serialization support exists. If a core developer would like to give me a hint as to which solution fits best, I will try my hand at a patch.