You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The generated import should be from parent.first_app.models import SomeModel, but instead it's just from first_app.models import SomeModel, which is incorrect. What's worse, this should actually be an ImportError, but the loaddata processing is eating it somehow and "No fixtures found." is printed, adding to the confusion.
The problem lies in the simplistic app name / model name combining logic to create the import rows, located in the dump_class_fixtures() function of utils/serialization.py.
The text was updated successfully, but these errors were encountered:
When a Django app package is a subpackage of a non-app package,
dumpdata
generates an incorrect import for that package.For example:
The generated import should be
from parent.first_app.models import SomeModel
, but instead it's justfrom first_app.models import SomeModel
, which is incorrect. What's worse, this should actually be anImportError
, but the loaddata processing is eating it somehow and "No fixtures found." is printed, adding to the confusion.The problem lies in the simplistic app name / model name combining logic to create the import rows, located in the
dump_class_fixtures()
function of utils/serialization.py.The text was updated successfully, but these errors were encountered: