| Age | Commit message (Collapse) | Author |
|---|
|
TransactionTestCase when using --keepdb."
This reverts commits b3b1d3d45fc066367f4fcacf0b06f72fcd00a9c6 and
9fa0d3786febf36c87ef059a39115aa1ce3326e8 due to reverse build failures
for which a solution isn't forthcoming.
|
|
using --keepdb.
Data loaded in migrations were restored at the beginning of each
TransactionTestCase and all the tables are truncated at the end of
these test cases. If there was a TransactionTestCase at the end of
the test suite, the migrated data weren't restored in the database
(especially unexpected when using --keepdb). Now data is restored
at the end of each TransactionTestCase.
|
|
so it's less likely to overflow.
TransactionTestCase.assertNumQueries() fails in an overflow situation.
|
|
|
|
serialized_rollback.
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().
|
