This reverts commit 49eee84245b1297a84ad4ddc2251e287ef585ea2 as it caused
a regression with test mirrors.
Backport of ce737ac67845da9a73ad645d6b9fb1692390ad56 from master
urlparse() fails with an AttributeError ("'__proxy__' object has no
attribute 'decode'") if reverse_lazy is used to look up the URL
(this is exactly the same problem that caused ticket #18776). The
solution is to use force_str() on the path before handing it to
urlparse().
Since --parallel is documented not to work on Windows, it's better to
ignore it and run without parallelization than to crash. For example
this could simplify cross-platform test scripts.
Notably it will fail to report a Model.DoesNotExist exceptions because
the class itself isn't pickleable. (Django has specific code to make its
instances pickleable.)
Use the same code path for:
- a database that has the same settings as another database
(as defined by test_db_signature)
- a database this is defined as a mirror of another database
There's no conceptual difference between these two cases.
Thanks Shai for the suggestion.
Moved the lookup in Field.swappable_setting to Apps, and added
an lru_cache to cache the results.
Refs #24743
Thanks Marten Kenbeek for the initial work on the patch. Thanks Aymeric
Augustin and Tim Graham for the review.
When using a TransactionTestCase with serialized_rollback=True,
after creating the database and running its migrations (along with
emitting the post_migrate signal), the contents of the database
are serialized to _test_serialized_contents.
After the first test case, _fixture_teardown() would flush the
tables but then the post_migrate signal would be emitted and new
rows (with new PKs) would be created in the django_content_type
table. Then in any subsequent test cases in a suite,
_fixture_setup() attempts to deserialize the content of
_test_serialized_contents, but these rows are identical to the
rows already in the database except for their PKs. This causes an
IntegrityError due to the unique constraint in the
django_content_type table.
This change made it so that in the above scenario the post_migrate
signal is not emitted after flushing the tables, since it will be
repopulated during fixture_setup().
* Converted the ``libraries`` and ``builtins`` globals of
``django.template.base`` into properties of the Engine class.
* Added a public API for explicit registration of libraries and builtins.
The primary use case is to interact with a third-party database (not
primarily managed by Django) that doesn't support time zones and where
datetimes are stored in local time when USE_TZ is True.
Configuring a PostgreSQL database with the TIME_ZONE option while USE_TZ
is False used to result in silent data corruption. Now this is an error.
