> 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.
That's a good question. It would save all the wrapper writers some
time. I don't think the library is the place to put thread safe
code for several reasons:
Some of us don't use threads and don't need thread
safe code.
I prefer modular code with as little mixing of function
as possible. It makes it easier for me to reuse code in
other projects. (For example: Don't put GUI messagebox
code to report errors into sqlite. I might want to use it in
an mp3 player, which doesn't have a GUI.)
Since it's very operating system dependent it would
be difficult for Dr. Hipp to test. He doesn't have a copy of every
operating system and every version at his office. He probably
doesn't know how to write thread safe code on every OS either.
I think it's better if that is left to people that have the
ability to do it correctly.
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
