Comparing
integration/sql-nested-transactions2
(e943433
) withmain
(f2e5886
)0%
- Improvements
- 0
- Regressions
- 0
- Untouched
- 11
- New
- 0
- Dropped
- 0
- Ignored
- 0
Benchmarks
Passed
medium_read
query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::medium_read0%
293.4 µs
292.5 µs
large_read
query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::large_read0%
1.6 ms
1.5 ms
mutation
query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::mutation0%
6.3 ms
6.3 ms
validate (medium)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (medium)0%
11.8 ms
11.8 ms
validate (small)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (small)0%
1.8 ms
1.8 ms
validate (large)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::psl::validate (large)0%
52.4 ms
52.4 ms
build (small)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (small)0%
266.3 µs
266.6 µs
small_read
query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::small_read0%
106.2 µs
106.4 µs
build (large)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (large)0%
4.5 ms
4.5 ms
deep_read_query
query-engine/request-handlers/benches/query_planning_bench.rs::benches::criterion_benchmark::deep_read_query-1%
1.8 ms
1.8 ms
build (medium)
query-engine/schema/benches/schema_builder_bench.rs::benches::criterion_benchmark::schema_builder::build (medium)-1%
2.2 ms
2.2 ms
Commits
Click on a commit to change the comparison rangeBase
main
f2e5886
0%
feat: add support for nested transaction rollbacks via savepoints in sql
This is my first OSS contribution for a Rust project, so I'm sure I've
made some stupid mistakes, but I think it should mostly work :)
This change adds a mutable depth counter, that can track how many levels
deep a transaction is, and uses savepoints to implement correct rollback
behaviour. Previously, once a nested transaction was complete, it would
be saved with `COMMIT`, meaning that even if the outer transaction was
rolled back, the operations in the inner transaction would persist. With
this change, if the outer transaction gets rolled back, then all inner
transactions will also be rolled back.
Different flavours of SQL servers have different syntax for handling
savepoints, so I've had to add new methods to the `Queryable` trait for
getting the commit and rollback statements. These are both parameterized
by the current depth.
I've additionally had to modify the `begin_statement` method to accept a depth
parameter, as it will need to conditionally create a savepoint.
When opening a transaction via the transaction server, you can now pass
the prior transaction ID to re-use the existing transaction,
incrementing the depth.
Signed-off-by: Lucian Buzzo <lucian.buzzo@gmail.com>
f486ca2
2 years ago
by LucianBuzzo0%
remove debug logs
e943433
1 year ago
by LucianBuzzo