Django's test suite often tries to load fixture files from apps that have
no fixtures at all. This creates a lot of unnecessary disabling and
enabling of constraints which can be expensive on some database.
To speed this up, loaddata now first checks if any fixture file matches.
If no fixture file is matched, then the command exits before disabling
and enabling of constraints is done.
The main benefit of this change is seen on MSSQL, where tests on
Django 1.8 run hours faster.
Previous versions of the tests were buggy, as initial_data.json
did exist and the test wasn't failing. It was finally failing on
Python 3.4.2.
Thanks Raphaël Hertzog for the report (and Debian bug #765117
contributors).
When invoked as follows:
$ python manage.py dumpdata blogapp blogapp.Tag
Django would throw a TypeError. This commit fixes the problem and provides
a test.
Added ``--natural-foreign`` and ``--natural-primary`` options and
deprecated the ``--natural`` option to the ``dumpdata`` management
command.
Added ``use_natural_foreign_keys`` and ``use_natural_primary_keys``
arguments and deprecated the ``use_natural_keys`` argument to
``django.core.serializers.Serializer.serialize()``.
Thanks SmileyChris for the suggestion.
The failure was caused by generating the same warning from two tests.
The second time the same warning was raised it was swallowed by the
"once" simplefilter of warnings.
If the fixture doesn't exist, loaddata will output a warning.
The fixture named "initial_data" is exceptional though; if it
doesn't exist, the warning is not emitted. This allows syncdb and
flush management commands to attempt to load it without causing
spurious warnings.
Thanks to Derega, ptone, dirigeant and d1ffuz0r for contributions
to the ticket.
The fixture named "initial_data" is exceptional though; if it
doesn't exist, the error is not raised. This allows syncdb and
flush management commands to attempt to load it without causing
an error if it doesn't exist.