Fixture loading issue with multi database setting
|Reported by:||linovia||Owned by:||nobody|
|Has patch:||no||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Here is another issue with multi database setting and tests about fixture loading.
I have a setup with one legacy database and one dedicated to django.
In order to pass my tests, I load 2 fixture files. One is some administrative data for every test case and relating only to the django dedicated DB. The second fixture file is about test data which are loaded in the two files.
The fixtures load correctly on the django database but will fail to load in the legacy database.
The fixture loader notices that the administrative data fixture file has NO data and will rollback at this point.
While this might be fine in a single database setup, it shouldn't rollback here since data were already loaded in the other database.
# If the fixture we loaded contains 0 objects, assume that an # error was encountered during fixture loading. if objects_in_fixture == 0: sys.stderr.write( self.style.ERROR("No fixture data found for '%s'. (File format may be invalid.)" % (fixture_name))) transaction.rollback(using=using) transaction.leave_transaction_management(using=using) return
According to me:
- it would make sense to issue a warning, but one should probably add the database name in order to discard any confusing error message.
- one should rollback if such error occur (the user has been notified about it)
Maybe a better solution would be to let the test framework load a fixture in both database in a single call but that would require a major rework of the loaddata command and could possibly have side effects if one uses same class but different objects on different databases.
Change History (11)
comment:1 Changed 6 years ago by linovia
- Needs documentation unset
- Needs tests unset
- Patch needs improvement unset
comment:3 Changed 5 years ago by russellm
- Resolution set to invalid
- Status changed from new to closed
comment:4 Changed 5 years ago by linovia
- Resolution invalid deleted
- Status changed from closed to reopened
Changed 5 years ago by linovia
comment:7 Changed 5 years ago by russellm
- Component changed from Uncategorized to Serialization
- Triage Stage changed from Unreviewed to Accepted
comment:9 Changed 5 years ago by russellm
- Resolution set to fixed
- Status changed from reopened to closed