pytest-dev / pytest-dev/pytest-django
`transactional_db` will ignore `--keep-db` and always flush the db after the test
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.5k
- Forks
- 367
- PR merge metrics
- No merged PRs in 30d
Description
I haven't found this exact issue anywhere, apologies if I missed something.
My special use-case is (ab-)using pytest-django for integration tests on a real server (of course not in production) and I was using the following fixture to prevent database setup and teardown:
@pytest.fixture(scope="session")
def django_db_setup():
return
(With the database being set up for the test in separate code.)
With the normal django_db and db markers/fixtures this works and doesn't flush the database. As soon as I add transaction=True or use transactional_db the database is always flushed.
The reason the flushing is done is that TransactionTestCase calls the flush command in its teardown method.
As a workaround I resorted to using the following fixture instead of transactional_db:
@pytest.fixture(scope="function")
def my_integration_transactional_db(request, django_db_setup,
django_db_blocker):
"""cannibalized from transactional_db fixture
but without the possible customization
- Won't check if we're called from a django testcase
- Won't reset sequences
- Don't care if we're called from a live server (that's handled
from the live_server fixture
)
- And MOST IMPORTANTLY: won't perform teardown (NO FLUSH!)
"""
django_db_blocker.unblock()
request.addfinalizer(django_db_blocker.restore)
from django.test import TransactionTestCase
test_case = TransactionTestCase(methodName="__init__")
test_case._pre_setup()
The most important thing here is that I skip the finalizer altogether (which works in my special use-case if database setup and teardown is done separately).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the transactional_db fixture and compare its teardown behavior with django_db_setup and the --keep-db option. Read Django's TransactionTestCase teardown path, especially the flush operation, and check how transaction=True reaches it. Done means transactional_db respects --keep-db without flushing while preserving the documented fixture behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- backend, databases, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100