Transaction 3

[tyt2y3]

Continue #199 on #142

Tasks

• MockConnection support
• Rework Rocket support
• Test cases

[tyt2y3]

@nappa85 have you tried nested transaction, i.e. multiple begin() and mutiple commit() on same connection?

[tyt2y3]

Was there a reason where TransactionError is a standalone enum instead of being a variant of DbErr?
If not, I'd merge it into DbErr, and use a Box<dyn Error> for simplicity.

[nappa85]

Was there a reason where TransactionError is a standalone enum instead of being a variant of DbErr? If not, I'd merge it into DbErr, and use a Box<dyn Error> for simplicity.

I don't like "Boxdyning" things, adds an indirection that is often avoidable.
If I remember correctly, TransactionError was made to wrap the error returned from the closure, but distinct between transaction begin errors and closure errors.

[nappa85]

@nappa85 have you tried nested transaction, i.e. multiple begin() and mutiple commit() on same connection?

Not extensively TBH, but should be trivial...
Have you found problems?

[tyt2y3]

Not extensively TBH, but should be trivial... Have you found problems?

No. Am trying to write some test cases on this. It'd be great if you can share your experience on its behavior, and see if it aligns with my understanding.

[nappa85]

Not extensively TBH, but should be trivial... Have you found problems?

No. Am trying to write some test cases on this. It'd be great if you can share your experience on its behavior, and see if it aligns with my understanding.

Under a Transaction there always is a connection, so a nested transaction insists on the same connection of the top level transaction.
In facts there is no difference between running a query on the top level or in a nested level, the result would be the same.
If you think about a SQL console, when you type "START TRANSACTION" the parent transaction is unreachable until you close the child transaction, but you're using the same connection.
This is more or less the same, with the only difference that, if you used begin method, you still have access to the parent transaction object.

This is why I think it's trivial, "START TRANSACTION" is only another query you run on the connection, so if, e.g., query_all works, also begin should work.

[tyt2y3]

Just to remind myself of the nested transaction implementation of SQLx

https://github.com/launchbadge/sqlx/blob/b6e127561797fe9aababa24ec640275ecb9b42af/sqlx-core/src/transaction.rs#L218

[tyt2y3]

1a2bd13

I succeeded in implementing and testing the nested transaction in MockInterface.

Looks bright!

[nappa85]

How close are we to a stable release?

[tyt2y3]

I have gone through everything (code, API design & behavior) thoroughly. Everything seems clear now.

I am targeting 0.3 at mid October, probably end of this week!

[billy1624]

Is this complicated enough? 1280046 @tyt2y3

[tyt2y3]

Is this complicated enough? 1280046 @tyt2y3

Yes but we need more

[tyt2y3]

@billy1624 please add more test cases onto master