> > db.transaction do |dbh|
> > db.do('DELETE FROM tbl WHERE id = 5')
> > db['AutoCommit'] = true
> > end
> >
> > Because there wasn't a commit given, that shouldn't actually
> > delete the rows found, but by tossing that AutoCommit in there, it
> > should and will generate a nifty warning if AutoCommit sends the
> > above BEGIN/SET/COMMIT. -sc
>
> You can't be setting autocommit willy-nilly. What I was going to
> suggest is that we allow 'SET autocommit' only at the start of a
> transaction, and then have it take effect immediately. If you try
> autocommit when a transaction is already in progress from a previous
> statement, we throw an error.
But that'd result in at least two transactions per connection because
in my database class wrapper I turn autocommit off. Under any kind of
load or performance situations, that's pretty unacceptable. Granted
there's nothing that would need to be flushed to disk (hopefully), it
still strikes me that there would have to be some locking involved and
that would degrade the performance of the entire system.
If you're throwing an error in the middle of a transaction just
because of 'SET autocommit', aren't you already making an exception
and one that degrades the performance of the entire system as a
result?
I just saw Tom's post and it seems like something has to give
someplace... I'm not a fan of the idea of creating the special case,
don't get me wrong, but is there a reasonable alternative? -sc
--
Sean Chittenden
