> > > Well there is discussion on whether a SET with autocommit off should
> > > start a transaction if it is the first command. Right now it does, and
> > > clearly you have a case where it acts strangely.
> >
> > Problem is that through various DB APIs such as DBI, you can't
> > garuntee to the user doing development that that it's the 1st command
> > that they're performing.
>
> OK, but why does my suggestion not work:
>
> SET autocommit = ON;
> COMMIT;
Hrm... if I changed the DBI layer for Ruby to have:
db['AutoCommit'] = true
use 'SET autocommit = ON; COMMIT;' I think I'd be breaking tons of
applications where they wouldn't be expecting the commit.
> Yep, we don't like special cases and that is why we avoided it. Just
> explaining the special case causes all sorts of confusion, as you have
> seen from my emails.
Yup, exceptions aren't elegant, but since there's only one way of
SET'ting variables and this one is very key to transactions, I don't
know of another way than possibly creating a parallel command to SET
that'd avoid this rollback/commit silliness... but that seems like a
step backwards and is why I'd think an exception would be good. -sc
--
Sean Chittenden
