#37077: TransactionTestCase.serialized_rollback doesn't run tests when database
includes a mirror in parallel
-------------------------------------+-------------------------------------
               Reporter:  Jake       |          Owner:  Jake Howard
  Howard                             |
                   Type:             |         Status:  assigned
  Uncategorized                      |
              Component:  Database   |        Version:  5.2
  layer (models, ORM)                |
               Severity:  Normal     |       Keywords:
           Triage Stage:             |      Has patch:  0
  Unreviewed                         |
    Needs documentation:  0          |    Needs tests:  0
Patch needs improvement:  0          |  Easy pickings:  0
                  UI/UX:  0          |
-------------------------------------+-------------------------------------
 In a very specific situation, the test runner skips running tests, and
 just terminates (successfully). Instead of running the tests, the database
 is set up, cloned for each process, then destroyed without running any
 tests. This is related to the changes from #35967

 With a `TransactionTestCase` with `serialized_rollback=True`, and a
 project with multiple `DATABASES` where one is a mirror of the other,
 where both connections are needed for the test (eg `databases =
 "__all__"). If a `TransactionTestCase` isn't going to be run, this
 behaviour isn't seen.

 The cause is that in `ParallelTestSuite.initialize_suite`, an
 `AttributeError` is raised when accessing
 `connections[alias]._test_serialized_contents`, because contents is never
 set.

 This could be resolved in 2 ways (at least that I've found):

 1. In `django.test.utils.setup_databases`. `serialize_connections` is
 never added to for mirrored aliases, meaning the contents is never
 serialized.
 2. In `DiscoveryRunner.run_tests`. `suite.serialized_aliases` is set to
 all databases, and doesn't exclude mirrors (where serialization isn't
 necessary).

 I've written (crude) fixes for both, and both resolve the issue, but I'm
 not sure which makes the most sense (maybe both?). I suspect the correct
 answer is option 2, since serializing (and restoring) mirrors makes little
 sense, but interested in some more opinions.

 I've tested this issue is also present on 5.2 (requires `spawn`
 multiprocessing mode).
-- 
Ticket URL: <https://code.djangoproject.com/ticket/37077>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/0107019dd9c0c019-181a374b-b455-4718-8a5e-a9f0ff53a24d-000000%40eu-central-1.amazonses.com.

Reply via email to