[DB-SIG] Optional DB API Extensions
Federico Di Gregorio
fog@debian.org
25 Oct 2001 16:04:38 +0200
--=-s1DZ3sM0qif1i3WtoptS
Content-Type: multipart/alternative; boundary="=-pTfvDSRIJM2Uhtp+DAC+"
--=-pTfvDSRIJM2Uhtp+DAC+
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
On Thu, 2001-10-25 at 14:02, Stuart Bishop wrote:
[snip]
> > but we need dictionaries able to cope with multiple equal keys (some db
> > allow multiple columns with the same name). also, should the keys be
> > compared ci or cs?
>=20
> I would keep it simple - dictionary keys are as taken from=20
> cursor.description,
> and behavior undefined if your SQL manages to return columns with the=20
> same name.=20
undefined behavior id definitely unportable. :)
> I havn't used a DB that actually lets me do this that I know of.
hihi (isteric mood). postgresql obviously. sic.
> > i am working on this for psycopg. it is somewhat simplier that your
> > proposal, just a way to ask the db for a given isolation level. or are
> > isolation levels defined at the SQL standard level?
>=20
> The transaction isolation levels are defined by SQL99 (I think - I=20
> cheated
> and used the JDBC docs rather than wade through the official specs. The
> proposal was pretty much identical to what JDBC offers in fact).
>=20
> What I had proposed was fairly simple when summarised.
> Methods:
> con.default_transaction_level
> con.set_transaction_level(lev)
> lev is one of:
> TRANSACTION_NONE
> TRANSACTION_READ_UNCOMMITTED
> TRANSACTION_READ_COMMITTED
> TRANSACTION_REPEATABLE_READ
>=20
> con.set_transaction_level sets the level as requested, or a higher=20
^^^^^
lower? anyway, what's the transaction level as defined in the dbapi
specs? i don't think dbapi specifies one for db that support multiple.
> Here are the relevant definitions and such if anyone is interested...
[snip]
> TRANSACTION_SERIALIZABLE
>=20
> Specifies that dirty reads, nonrepeatable reads, and phantom
> reads are prevented.
psycopg uses this one. thank you very much for the explanation. i would
like to see this proposal about transaction levels in the dbapi
extensions too.
--=20
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact fog@debian.org
INIT.D Developer fog@initd.org
Don't dream it. Be it. -- Dr. Frank'n'further
--=-pTfvDSRIJM2Uhtp+DAC+
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/0.15.0">
</HEAD>
<BODY>On Thu, 2001-10-25 at 14:02, Stuart Bishop wrote:<br>
[snip]<pre><FONT COLOR=3D"#737373">> > but we need dictionaries able =
to cope with multiple equal keys (some db</FONT>
<FONT COLOR=3D"#737373">> > allow multiple columns with the same name=
). also, should the keys be</FONT>
<FONT COLOR=3D"#737373">> > compared ci or cs?</FONT>
<FONT COLOR=3D"#737373">> </FONT>
<FONT COLOR=3D"#737373">> I would keep it simple - dictionary keys are a=
s taken from </FONT>
<FONT COLOR=3D"#737373">> cursor.description,</FONT>
<FONT COLOR=3D"#737373">> and behavior undefined if your SQL manages to =
return columns with the </FONT>
<FONT COLOR=3D"#737373">> same name. </FONT></pre>undefined behavior id =
definitely unportable. :)<pre><FONT COLOR=3D"#737373">> I havn't used a =
DB that actually lets me do this that I know of.</FONT></pre>hihi (isteric =
mood). postgresql obviously. sic.<pre><FONT COLOR=3D"#737373">> > i a=
m working on this for psycopg. it is somewhat simplier that your</FONT>
<FONT COLOR=3D"#737373">> > proposal, just a way to ask the db for a =
given isolation level. or are</FONT>
<FONT COLOR=3D"#737373">> > isolation levels defined at the SQL stand=
ard level?</FONT>
<FONT COLOR=3D"#737373">> </FONT>
<FONT COLOR=3D"#737373">> The transaction isolation levels are defined b=
y SQL99 (I think - I </FONT>
<FONT COLOR=3D"#737373">> cheated</FONT>
<FONT COLOR=3D"#737373">> and used the JDBC docs rather than wade throug=
h the official specs. The</FONT>
<FONT COLOR=3D"#737373">> proposal was pretty much identical to what JDB=
C offers in fact).</FONT>
<FONT COLOR=3D"#737373">> </FONT>
<FONT COLOR=3D"#737373">> What I had proposed was fairly simple when sum=
marised.</FONT>
<FONT COLOR=3D"#737373">> Methods:</FONT>
<FONT COLOR=3D"#737373">> con.default_transaction_level</FONT>
<FONT COLOR=3D"#737373">> con.set_transaction_level(lev)</FONT>
<FONT COLOR=3D"#737373">> lev is one of:</FONT>
<FONT COLOR=3D"#737373">> TRANSACTION_NONE</FONT>
<FONT COLOR=3D"#737373">> TRANSACTION_READ_UNCOMMITTED</FONT>
<FONT COLOR=3D"#737373">> TRANSACTION_READ_COMMITTED</FONT>
<FONT COLOR=3D"#737373">> TRANSACTION_REPEATABLE_READ</FONT>
<FONT COLOR=3D"#737373">> </FONT>
<FONT COLOR=3D"#737373">> con.set_transact=
ion_level sets the level as requested, or a higher </FONT></pre>  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp; ^^^^^<br>
lower? anyway, what's the transaction level as defined in the dbapi specs? =
i don't think dbapi specifies one for db that support multiple.<pre><FONT C=
OLOR=3D"#737373">> Here are the relevant definitions and such if anyone =
is interested...</FONT>
<FONT COLOR=3D"#737373">[snip]</FONT>
<FONT COLOR=3D"#737373">> TRANSACTION_SERIALIZABLE</FONT>
<FONT COLOR=3D"#737373">> </FONT>
<FONT COLOR=3D"#737373">> Specifies that dirty reads, nonre=
peatable reads, and phantom</FONT>
<FONT COLOR=3D"#737373">> reads are prevented.</FONT>
<FONT COLOR=3D"#737373"></FONT></pre><FONT COLOR=3D"#737373">psycopg uses t=
his one. thank you very much for the explanation. i would like to see this =
proposal about transaction levels in the dbapi extensions too.</FONT><br>
<FONT COLOR=3D"#737373"></FONT><TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" W=
IDTH=3D"100%">
<TR>
<TD>
<pre>--=20
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact fog@debian.or=
g
INIT.D Developer fog@initd.org
Don't dream it. Be it. -- Dr. Frank'n'further</p=
re></TD>
</TR>
</TABLE>
</BODY>
</HTML>
--=-pTfvDSRIJM2Uhtp+DAC+--
--=-s1DZ3sM0qif1i3WtoptS
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjvYG/YACgkQvcCgrgZGjesmRgCcCSslkNgHsQQAPjZAVNc48Hqn
LZkAnAz/M4GixDPZciUla9HuOR0/TV1X
=7IHR
-----END PGP SIGNATURE-----
--=-s1DZ3sM0qif1i3WtoptS--