- attached nested_rollback.html
Difference between flushing in outer transaction and committing in nested transaction
After introducing nested transactions into our software I was greeted with a flurry of ObjectDeletedErrors. It turned out that it makes a huge difference if a change is committed inside a nested transaction or flushed inside the main transaction.
From the database side I expect these to be equivalent:
Original instructions
begin;
-- add stuff to the database
rollback;
Updated instructions using nested transactions
begin;
savepoint inner;
-- add stuff to the database
release savepoint inner;
rollback;
Rationale
When the instructions inside the nested transaction complete successfully, it should make no difference if they are inside a savepoint demarcation or not.
Example code
Please have a look at the attached file nested_rollback.rst. It runs to completion here without error but illustrates the current problem. You can run it using
python -m doctest nested_rollback.rst
This seems to be related to issue #2658.
Comments (7)
-
reporter -
repo owner - changed status to resolved
- Fixed bug where items that were persisted, deleted, or had a
primary key change within a savepoint block would not
participate in being restored to their former state (not in
session, in session, previous PK) after the outer transaction
were rolled back. fixes
#3108
→ <<cset 0d6831448b55>>
-
repo owner - Fixed bug where items that were persisted, deleted, or had a
primary key change within a savepoint block would not
participate in being restored to their former state (not in
session, in session, previous PK) after the outer transaction
were rolled back. fixes
#3108
→ <<cset 427ee3a61e97>>
- Fixed bug where items that were persisted, deleted, or had a
primary key change within a savepoint block would not
participate in being restored to their former state (not in
session, in session, previous PK) after the outer transaction
were rolled back. fixes
-
reporter Incredible. Do you ever sleep, Mike? Thanks a bunch!
-
repo owner an issue like this is A. severe, in that it's really wrong, and it's like amazing nobody has come across it yet, but then B. not any kind of architectural issue, just a small rule that was missing. Also issues that are fundamental like these can often mess up apps that rely upon broken behavior. So they are very low effort to fix but really critical to get out ASAP.
There's a crap-ton of issues and pullrequests that aren't so critical that are just sitting around :).
-
repo owner - changed milestone to 0.9.8
-
repo owner - changed milestone to 0.9.7
- Log in to comment