|
| 1 | +=begin pod |
| 2 | +
|
| 3 | +=head1 SAVEPOINT Support in Red |
| 4 | +
|
| 5 | +Red now supports database savepoints for better handling of nested transactions. This addresses issues where nested transactions using separate connections could lead to isolation problems. |
| 6 | +
|
| 7 | +=head2 Automatic Savepoint Usage |
| 8 | +
|
| 9 | +When you start a nested transaction using C<begin>, Red automatically uses savepoints instead of creating new database connections: |
| 10 | +
|
| 11 | +=begin code :lang<raku> |
| 12 | +use Red:api<2>; |
| 13 | +
|
| 14 | +model Person is rw { |
| 15 | + has Int $.id is serial; |
| 16 | + has Str $.name is column; |
| 17 | +} |
| 18 | +
|
| 19 | +my $*RED-DB = database "SQLite"; |
| 20 | +Person.^create-table; |
| 21 | +
|
| 22 | +# Start main transaction |
| 23 | +my $main-tx = $*RED-DB.begin; |
| 24 | +
|
| 25 | +{ |
| 26 | + my $*RED-DB = $main-tx; |
| 27 | + my $person1 = Person.^create(:name("Alice")); |
| 28 | + |
| 29 | + # Start nested transaction (creates savepoint automatically) |
| 30 | + my $nested-tx = $main-tx.begin; |
| 31 | + |
| 32 | + { |
| 33 | + my $*RED-DB = $nested-tx; |
| 34 | + my $person2 = Person.^create(:name("Bob")); |
| 35 | + |
| 36 | + # Rollback nested transaction (rolls back to savepoint) |
| 37 | + $nested-tx.rollback; # Only Bob is rolled back |
| 38 | + } |
| 39 | + |
| 40 | + # Alice is still there |
| 41 | + $main-tx.commit; |
| 42 | +} |
| 43 | +=end code |
| 44 | +
|
| 45 | +=head2 Manual Savepoint Operations |
| 46 | +
|
| 47 | +You can also create and manage savepoints manually: |
| 48 | +
|
| 49 | +=begin code :lang<raku> |
| 50 | +my $tx = $*RED-DB.begin; |
| 51 | +my $*RED-DB = $tx; |
| 52 | +
|
| 53 | +my $person1 = Person.^create(:name("Alice")); |
| 54 | +
|
| 55 | +# Create a named savepoint |
| 56 | +$*RED-DB.savepoint("checkpoint1"); |
| 57 | +
|
| 58 | +my $person2 = Person.^create(:name("Bob")); |
| 59 | +
|
| 60 | +# Rollback to the savepoint |
| 61 | +$*RED-DB.rollback-to-savepoint("checkpoint1"); # Bob is rolled back |
| 62 | +
|
| 63 | +# Or release the savepoint when no longer needed |
| 64 | +$*RED-DB.savepoint("checkpoint2"); |
| 65 | +my $person3 = Person.^create(:name("Charlie")); |
| 66 | +$*RED-DB.release-savepoint("checkpoint2"); # Just removes the savepoint |
| 67 | +
|
| 68 | +$tx.commit; # Alice and Charlie are committed |
| 69 | +=end code |
| 70 | +
|
| 71 | +=head2 Database Support |
| 72 | +
|
| 73 | +Savepoints are supported on: |
| 74 | +
|
| 75 | +=item PostgreSQL - Full SAVEPOINT/ROLLBACK TO SAVEPOINT/RELEASE SAVEPOINT syntax |
| 76 | +=item MySQL - Full SAVEPOINT/ROLLBACK TO SAVEPOINT/RELEASE SAVEPOINT syntax |
| 77 | +=item SQLite - SAVEPOINT/ROLLBACK TO/RELEASE syntax (simplified) |
| 78 | +
|
| 79 | +=head2 API Methods |
| 80 | +
|
| 81 | +=head3 Automatic Transaction Context |
| 82 | +
|
| 83 | +=item C<$driver.begin()> - Returns a transaction context that uses savepoints for nesting |
| 84 | +=item C<$tx.begin()> - Creates a nested savepoint context |
| 85 | +=item C<$tx.commit()> - Commits transaction or releases savepoint |
| 86 | +=item C<$tx.rollback()> - Rolls back transaction or rolls back to savepoint |
| 87 | +
|
| 88 | +=head3 Manual Savepoint Control |
| 89 | +
|
| 90 | +=item C<$driver.savepoint($name)> - Creates a named savepoint |
| 91 | +=item C<$driver.rollback-to-savepoint($name)> - Rolls back to a named savepoint |
| 92 | +=item C<$driver.release-savepoint($name)> - Releases a named savepoint |
| 93 | +
|
| 94 | +=head2 Implementation Details |
| 95 | +
|
| 96 | +The savepoint implementation uses a C<TransactionContext> wrapper that: |
| 97 | +
|
| 98 | +=item Maintains API compatibility with existing transaction code |
| 99 | +=item Uses the same underlying database connection for all nested levels |
| 100 | +=item Automatically translates nested transactions to savepoints |
| 101 | +=item Provides promise-based coordination for cleanup |
| 102 | +=item Delegates all driver methods to the parent connection |
| 103 | +
|
| 104 | +This ensures that changes made in outer transactions are visible to inner transactions, solving the isolation issues that occurred with the previous approach of using separate connections. |
| 105 | +
|
| 106 | +=end pod |
0 commit comments