John LeSueur wrote:
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
Kervin L. Pierre wrote:
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
On Fri, Apr 01, 2005 at 01:56:16PM -0500, Ned Batchelder wrote:
> I decided for my own work that magic nested transactions are a bad idea. To
> properly handle errors and rollback the database, you need to know where the
> edges of the transaction really are. Fully-supported nested transactions
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
Ned Batchelder wrote:
I went through this same issue in my application, and realized that
rollbacks throw off the whole scheme. This proposal doesn't account for
rollbacks: how would they work? If only the outermost "transaction" would
truly perform a rollback, then what would an inner one do?
-Ned.
http://nedbatchelder.com
-Original Message-
From: Eli Burke [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 12:33 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] idea: sqlite3_begin() and sqlite3_end() ?
>That's a good question. It would save all the wrapper writers
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
> 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
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
> 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.
Hello,
[ Sorry for the second email, but I wanted to
separate this ]
Would a...
sqlite3_begin(sqlite3 *db, int type)
sqlite3_end( sqlite3 *db )
be helpful for people counting transactions
in a thread environment?
The only difference to doing the 'transaction
level' counting yourself is that
11 matches
Mail list logo
