Jay wrote:
The begin and end functions could be configured
to begin/end the transaction *if* there isn't/is
one.
Dumb idea?
Do I get get to wear the dunce hat? :)
You should really look at an object oriented language.
You can do exactly this very simply.
But why should he have to? This is not a dumb idea, Jay. We are told that sqlite3_exec is for "legacy code support", which means that the only recommended option must be to use sqlite3_prepare/step/final for transactions. That's a fair bit of code (plus error checking) to put in every place you want to BEGIN, COMMIT, or ROLLBACK a transaction.
Logically then, many people are creating wrapper functions for transactions. Why not add direct API calls and avoid the extra effort on everyone's part. And if it happens to implement reference counting (thread-safe!), so much the better. I know know one of the goals here is for a robust lightweight library, but sqlite3_begin/commit/rollback could save a decent amount of effort on the part of current and future users.
Not to mention if transaction refcounting is implemented internally, you don't
have to worry about whether or not embedded or user-supplied SQL code
contains additional transactions. Or pass around the current transaction state
between functions, as I have done in the past. Or worry about implementing
and testing ref-counts using thread-local storage.
Support for ref counts must be already present in some measure in sqlite3
because sqlite_exec creates an implicit transaction if none exists, so this
doesn't seem like a huge stretch. If nothing else, it would be nice to have
an API call or pragma that will indicate if a transaction is currently active.
-Eli
