mirror of https://github.com/django/django.git
d3fdaf907d
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(). |
||
|---|---|---|
| .. | ||
| _images | ||
| auth | ||
| class-based-views | ||
| db | ||
| forms | ||
| http | ||
| i18n | ||
| testing | ||
| cache.txt | ||
| checks.txt | ||
| conditional-view-processing.txt | ||
| email.txt | ||
| external-packages.txt | ||
| files.txt | ||
| index.txt | ||
| install.txt | ||
| logging.txt | ||
| migrations.txt | ||
| pagination.txt | ||
| performance.txt | ||
| python3.txt | ||
| security.txt | ||
| serialization.txt | ||
| settings.txt | ||
| signals.txt | ||
| signing.txt | ||
| templates.txt | ||