django.git/django/db/transaction.py, branch stable/6.0.x

Refs #36500 -- Rewrapped long docstrings and block comments via a script.

2025-07-23T23:17:55Z

Rewrapped long docstrings and block comments to 79 characters + newline using script from https://github.com/medmunds/autofix-w505.

Fixed typos in Atomic docstring.

2024-07-22T06:27:27Z

Fixed #23353 -- Used "raise from" when raising TransactionManagementError.

2022-10-03T04:08:54Z

This change sets the __cause__ attribute to raised exceptions.

Fixed #33616 -- Allowed registering callbacks that can fail in transaction.on_commit().

2022-09-06T10:21:36Z

Thanks David Wobrock and Mariusz Felisiak for reviews.

Refs #33476 -- Reformatted code with Black.

2022-02-07T19:37:05Z

Fixed #33161 -- Enabled durability check for nested atomic blocks in TestCase.

2021-11-12T12:05:56Z

Co-Authored-By: Adam Johnson

Fixed #32220 -- Added durable argument to transaction.atomic().

2020-11-27T20:43:15Z

Fixed #30116 -- Dropped support for Python 3.5.

2019-01-30T15:19:48Z

Refs #27025 -- Removed obsolete sqlite3 transaction management workaround for Python 3.6+.

2018-10-25T23:54:48Z

Obsolete per https://bugs.python.org/issue10740#msg274816.

Fixed #21171 -- Avoided starting a transaction when a single (or atomic queries) are executed.

2018-10-17T10:19:02Z

Checked the following locations: * Model.save(): If there are parents involved, take the safe way and use transactions since this should be an all or nothing operation. If the model has no parents: * Signals are executed before and after the previous existing transaction -- they were never been part of the transaction. * if `force_insert` is set then only one query is executed -> atomic by definition and no transaction needed. * same applies to `force_update`. * If a primary key is set and no `force_*` is set Django will try an UPDATE and if that returns zero rows it tries an INSERT. The first case is completly save (single query). In the second case a transaction should not produce different results since the update query is basically a no-op then (might miss something though). * QuerySet.update(): no signals issued, single query -> no transaction needed. * Model/Collector.delete(): This one is fun due to the fact that is does many things at once. Most importantly though: It does send signals as part of the transaction, so for maximum backwards compatibility we need to be conservative. To ensure maximum compatibility the transaction here is removed only if the following holds true: * A single instance is being deleted. * There are no signal handlers attached to that instance. * There are no deletions/updates to cascade. * There are no parents which also need deletion.