--
Ticket URL: <https://code.djangoproject.com/ticket/30005>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* stage: Unreviewed => Accepted
Comment:
I guess it's a typo in the original commit:
d7bc4fbc94df6c231d71dffa45cf337ff13512ee.
--
Ticket URL: <https://code.djangoproject.com/ticket/30005#comment:1>
* owner: nobody => Peter Hull
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/30005#comment:2>
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/10717 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/30005#comment:3>
Comment (by Simon Charette):
I don't think the example is wrong at all as the inner
`transaction.atomic` block creates a `SAVEPOINT` (because
`atomic(savepoint)` defaults to `True`) and thus the connection is usable
in the event of an `IntegrityError` because a rollback of the savepoint
would happen.
What the example is trying to demonstrate is that you can still nest
`transaction.atomic()` block safely if you wrap code expected to raise
database error appropriately and have queries within it's context be
atomic. In this case the `create_parent()` and `add_children()` calls will
be executed in the same transaction because of the function decorator.
Think of it this way, `atomic` would be completely impossible to use if
you couldn't nest calls this way given each calls to the database can
theoretically raise a database exception.
--
Ticket URL: <https://code.djangoproject.com/ticket/30005#comment:4>
* status: assigned => closed
* resolution: => invalid
--
Ticket URL: <https://code.djangoproject.com/ticket/30005#comment:5>