Difference between flushing in outer transaction and committing in nested transaction

Issue #3108 resolved
Torsten Landschoff created an issue

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)

  1. Mike Bayer 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 0d6831448b55>>

  2. Mike Bayer 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>>

  3. Mike Bayer 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 :).

  4. Log in to comment