Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add support for nested transaction rollbacks via savepoints in sql #4405

Closed
wants to merge 5 commits into from

Conversation

janpio
Copy link
Contributor

@janpio janpio commented Nov 1, 2023

Same as #4375 but in our repo to trigger Buildkite

@janpio janpio closed this Nov 1, 2023
@janpio janpio reopened this Nov 1, 2023
Copy link

codspeed-hq bot commented Nov 1, 2023

CodSpeed Performance Report

Merging #4405 will improve performances by 5.78%

Comparing integration/sql-nested-transactions (4c24703) with main (2963919)

Summary

⚡ 1 improvements
✅ 10 untouched benchmarks

Benchmarks breakdown

Benchmark main integration/sql-nested-transactions Change
large_read 7.6 ms 7.2 ms +5.78%

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.

Signed-off-by: Lucian Buzzo <[email protected]>
This allows an existing transaction ID to be used when starting a new
transaction, useful for nested transactions.

Signed-off-by: Lucian Buzzo <[email protected]>
@LucianBuzzo
Copy link
Contributor

@Jolg42 Dumb question: how do we now update prisma/prisma#21678 to use this buildkite release?

@janpio
Copy link
Contributor Author

janpio commented Nov 9, 2023

@LucianBuzzo @prisma/engines-version@5.6.0-22.integration-sql-nested-transactions-4c2470361c7aef1441e5cf3c5b517f19ab30c87a should have this engine version, if you update to that in the PR it should use it.

@Jolg42
Copy link
Contributor

Jolg42 commented Nov 9, 2023

Indeed, like Jan said, I can see it popped up as an automated PR here prisma/prisma#21852

@janpio janpio closed this Jan 10, 2024
@Jolg42 Jolg42 deleted the integration/sql-nested-transactions branch January 11, 2024 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants