[DB-SIG] Behaviour of .commit()/.rollback() when autocommit=True

[Denis S. Otkidach]

Only 1) and 2) are acceptable.  Rollback MUST raise exception if
it ever called since transaction can't be rolled back.

On Mon, 17 Nov 2003, [ISO-8859-1] Gerhard HДring wrote:

GH> Several database modules seem to have a sort of unofficial
GH> extension -
GH> the autocommit mode, without transaction handling. I'd like
GH> to hear your
GH> opinion on what .commit()/.rollback() should do in this
GH> case.
GH>
GH> Option 1)
GH>
GH> Behaviour: .commit() dies nothing, .rollback() raises an
GH> exception
GH>
GH> Rationale: this makes it easier to program applications that
GH> work in
GH> both autocommit mode and transactional mode, depending on
GH> the
GH> configuration or DB-API module used.
GH>
GH>
GH> Option 2)
GH>
GH> Behaviour: .commit() and .rollback() both raise an exception
GH> Rationale: There is nothing to commit or roll back, so these
GH> calls don't
GH> make any sense and the user should be alerted of this fact.
GH>
GH>
GH> Option 3)
GH>
GH> Behaviour: .commit() and .rollback() both do nothing.
GH>
GH> Rationale: (Almost) same as #1?
GH>
GH>
GH> Do you have any other suggestions? Which would you prefer?

-- 
Denis S. Otkidach
http://www.python.ru/      [ru]