Kervin L. Pierre wrote:
I think we can agree that sqlite3_begin() and sqlite3_end()/sqlite3_rollback() would be great convenience
Hello,
These functions are not supposed to be replace nested transactions. They just use the tools the API *already* has to make it easier to work with transactions in recursive and inter-dependent functions/methods.
sqlite3_rollback() would rollback the transaction. It does nothing else.
By you calling sqlite3_rollback() you have requesting the tranaction be cancelled.
Most likely, if you rollbacked back the transaction, you're in your error handling code/logic at that point right? Ie. You'd be propagating that error to your outer functions which would not bother continue with it's part of the transaction, for example.
Even if that assumtion is incorrect, you are responsible for dealing with letting the rest of your code know that you rollback the transaction.
Does this seem fair?
- Kervin
functions. It seems that we disagree about the library providing the convenience of emulating(in a limited sense)
nested transactions. That may be because I'm not sure exactly what you're proposing. sqlite3_rollback() would
always immediately rollback? and sqlite3_end() would only commit if it was the outermost "transaction"? For some
reason, it just feels like a bad idea for the library code to do this. Maybe it's the principle of least surprise. As a new
developer, coming to sqlite, if there was this reference counting and loosely emulated nested transactions, and one
day I made a mistake and called sqlite3_begin() twice and calling sqlite3_end() just once, nothing would be
committed. But since calling sqlite3_begin() twice didn't throw an error, I would be surprised and confused. I don't know if
that makes sense, or is enough reason to convince you, but in my mind, it makes this feel like a bad idea.
John
