[DB-SIG] Optional DB API Extensions
Fri, 26 Oct 2001 17:28:31 +1000
On Friday, October 26, 2001, at 12:04 AM, Federico Di Gregorio wrote:
> undefined behavior id definitely unportable. :)
Well, if your database doesn't refuse to process the SQL in
the first place, an exception would be thrown if you attempt to
coerce the result into a dictionary. Hows that?
> >=A0=A0=A0=A0=A0 con.set_transaction_level sets the level as =
requested, or a=20
> lower? anyway, what's the transaction level as defined in the dbapi=20
> specs? i don't think dbapi specifies one for db that support multiple.
Higher. Or I guess that this should be 'more protective'.
The rationalization for this is that if I need to set a specific=20
level, I want *at least* that amount of protection. As the method would=20=
the actual level set, if you application *does* require a particular=20
return code can be checked.
dbapi currently doesn't specify any transaction levels - this is left up=20=
to the drivers
to define and document.
> psycopg uses this one. thank you very much for the explanation. i =
> like to see this proposal about transaction levels in the dbapi=20
> extensions too.
So psycopg would have the trivial task of implementing this=20
def set_transaction_level(self,lev): return 4
def get_default_transaction_level(self): return 4
Note that unless a shared python module is being distributed, we need to=20=
the transaction isolation levels as integers as opposed to symbolic=20
the 'return 4' above.
Stuart Bishop <firstname.lastname@example.org>