Opened 16 years ago
Last modified 17 hours ago
#13680 assigned 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: | youngjae kwon | |
|---|---|---|---|
| Component: | Core (Serialization) | Version: | dev |
| 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
"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 (9)
comment:1 by , 16 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 16 years ago
comment:3 by , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → Cleanup/optimization |
comment:6 by , 13 years ago
| Component: | Core (Other) → Core (Serialization) |
|---|
comment:7 by , 2 weeks ago
Hi, I would like to work on this issue.
I understand that when loading fixtures without specifying the extension, Django fails to detect unsupported serialization formats and shows "No fixtures found" instead of a helpful warning.
I will start by reproducing the issue locally and then explore how fixture discovery works in loaddata.
Please let me know if there are any specific considerations.
comment:8 by , 19 hours ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
I'm going to work on this. I've reproduced the issue on the current main
branch — running loaddata test_data fails with "No fixture named
'test_data' found" even when test_data.bogus exists in the fixtures
directory, with no hint that the format is unrecognized.
Planning to add a fallback check: if no fixture matches the known
serialization formats, scan for files with the same basename and
report the unknown extension explicitly.
comment:9 by , 17 hours ago
| Has patch: | set |
|---|
PR submitted: https://github.com/django/django/pull/21194
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.