On 13/09/11 18:39, Chris Clark wrote:
[snip]
>>> The behaviour of setting autocommit when a transaction is already open
>>> is also to be seen: there are three basic option:
>>>
>>> - have a commit
>>> - have a rollback
>>> - have an error
>>>
>>> I feel the implicit commit is the most dangerous option. An implicit
>>> rollback may be more acceptable (it's the same behaviour of closing
>>> the connection with a transaction in progress): I proposed it for
>>> psycopg but, in the discussion, raising an exception proved the most
>>> popular option.
>>>
>>>
>> I don't think I know how to even determine whether there is a
>> transaction in progress in ADO.(*) If there is a way, then checking
>> on it just so that I can raise an exception seems expensive. Remember
>> that most of the time the resulting stack trace would not be seen by
>> the programmer who goofed up, but a completely innocent user -- and to
>> her it looks like the program just crashed for no reason. The
>> rollback would be easy to program and user friendly. I vote rollback.
>>
>
> The exception route has the potential to be the easiest for most DBMS
> implementations, most DBMSs will raise an error, so the driver doesn't
> need to track state and can just propagate the DBMS error. For some
> backends, state tracking would be required which is why I suggested the
> "easy" commit option. Rollback seems semi safe BUT when setting
> autocommit to ON the default behavior of a rollback seems a little
> surprising.
>
> I'm not in love with committing when the autocommit state is changed but
> for the "enable auto commit" operation it seems logical, the user is
> requesting commits take place under the covers. Conversely when
> disabling autocommit (after it has previously been enabled) we are
> either not in a transaction (due to auto commit being on) or we could
> still be fetching mid select, in which case a commit would be the same
> as a rollback. I.e. only impact on locking, any writes to the database
> would have been already auto committed.
[snap]
Client code can set .autocommit (yes, I am +1 for the attribute) to true
by two different code paths: the "correct" one and the "buggy" one. The
correct code path is not a problem: as long as the programmer knows the
behaviour she can do the right thing:
1. exception => make sure to commit() or rollback() before,
depending on the wanted outcome;
2. commit => rollback() if you don't want to commit changes,
do nothing in the other case;
3. rollback => as (2), reversed.
What I am interested in is the behaviour of the driver when the code
sets .autocommit to true following a buggy code path, i.e., when there
is a pending transaction and the code is unaware of it:
1. exception => pending transaction is lost, user (and eventually
also the programmer) gets a stack trace: this is
good because the user is sure about the outcome (data
is lost) _and_ has information about the problem;
2. commit => pending transaction is commited but it is what the
code was really supposed to do? noboby will know until
someone peeks at the database and _then_ a possibly
difficult bug hunting session begins;
3. rollback => as (2), but data is lost.
Having commit or rollbacks happen because of a bug really scares me:
spurious data starts to popup into the database and finding the bugs
usually isn't a piece of cake. That's why I vote for the exception.
federico
--
Federico Di Gregorio f...@initd.org
If nobody understand you, that doesn't mean you're an artist.
-- anonymous
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
