Julius de Bruijn
Julius de Bruijn
Not that I know of. Do you want to give it a try?
PR would be appreciated!
On vacation right now. Coming back to work on Monday, taking a look asap next week.
So, what should we expect here? Basically what we want is to get all the affected rows, so when parsing the server response, we count modifications from all procedures executed...
And, if you do not care about results per query, you can try out the [`ExecuteResult::total`](https://docs.rs/tiberius/0.5.15/tiberius/struct.ExecuteResult.html#method.total) method, that returns only one number that should reflect the total number of rows...
We'll be doing this as part of our GIS epic later this year or early next year, if nobody wants to do it before that.
So let's write the possibilities here: ## Calling method The transaction API could work in two ways. First is to return a transaction object: ```rust let mut tx = client.start_transaction().await?...
This pull request enables the basis for spawning transactions: https://github.com/prisma/tiberius/pull/55 On top of that change it should be possible to build a higher level transaction API.
Is there an actual need for transaction API in Tiberius? In the current state we can't guarantee an automatic `ROLLBACK` or `COMMIT` due to Rust not having a `PollDrop` trait,...
Yes. But typically you want to reuse the connection between requests, so you either hold it in a mutex, or use a connection pool. Not triggering a `ROLLBACK` might lead...