Vernon Cole wrote:
Properties are just the right tools for this
task, and appear to be the most used solution in popular drivers.
I think that term "attributes" is more commonly used, rather than
"properties", but I agree completely.
"conn.autocommit = True" seems pythonic, as does "if not
conn.autocommit". Getters and Setters feel like java. The
implementing programmer has getattr and setattr for exactly that
purpose, and the calling programmer has a clean interface.
Property is the correct name for this in Python, see
http://docs.python.org/library/functions.html
I agree using a property is a good idea, very easy to document and use.
If/when I get around to it ;-) that is the route I'll take with jyjdbc.
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.
So I think we have 3 people each advocating slightly different options
for what to do when changing auto commit options :-)
1. exception
2. commit
3. rollback
I'll be happy with what ever we as a group decide (so long as we
document it), I think committing will be least surprising for end users,
so whilst I'm not keen on it I feel I should champion it.
Are people happy with this rough approach (we can thrash out
exception/rollback/commit) where this is an optional extension, i.e. not
required?
Chris
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
