[DB-SIG] Optional DB API Extensions

[Stuart Bishop]

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
> higher
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ^^^^^
> 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
transaction isolation
level, I want *at least* that amount of protection. As the method would=20=

return
the actual level set, if you application *does* require a particular=20
level this
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 =
would=20
> 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
specification as:
	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=

define
the transaction isolation levels as integers as opposed to symbolic=20
constants (thus
the 'return 4' above.

--
Stuart Bishop <zen@shangri-la.dropbear.id.au>
http://shangri-la.dropbear.id.au/