[DB-SIG] Uittests for Python Database API Specification 2.0

Thierry MICHEL thierry.michel@nekhem.com
28 Nov 2002 01:54:55 +0100


On Wed, 2002-11-27 at 17:59, Gerhard H=E4ring wrote:
> * Michael Scharf <Michael_Scharf@gmx.de> [2002-11-27 17:35 +0100]:
> > Hi,
> >=20
> > are there any unit tests for the "Python Database API Specification 2.0=
".
>=20
> Federico has once start working on some. I believe I have seen them once
> somewhere at http://initd.org/, but can't find it currently.

I'm helping him to write entire test suite for DBAPI1.0 compliance.
Right now, I have personaly slow down the project, because I'm very busy
w/ my work. But, I think to continue this development soon.

>=20
> > I have seen some kind of tests in mxODBC, but I wonder if there is a se=
t
> > of unit tests that can be used to check the conformance to the PDAPI2.0=
?
>=20
> AFAIK nothing finished, currently.
>=20
> > [...] Another nice thing would be to have a set of performance tests ba=
sed on
> > the PDAPI2.0. That could be very helpful when to compare different
> > implementations.
>=20
> That'd mostly be useful for comparing different DB-API modules for the sa=
me
> database, as the DB-API wrappers have overhead, too. Sometimes quite
> considerable overhead. But for many applications, this is not a problem a=
t all.
>=20
> > There are so many databases and it's really hard to
> > decide which one to use (given some performance constraints)...
> >=20
> > What's also interesting sometimes it the disk space (% of wasted disk
> > space given a data set) and (maximum) memory usage of a database.
> >=20
> > Finally, installation size is important sometimes.
>=20
> These are all characteristica of the RDBMS used. And unfortunately, it's =
hard
> to get such data, because it fall in the benchmark category. And the comm=
ercial
> RDMBS vendors are such losers that they all forbid publishing benchmark r=
esults
> in their license agreements.
>=20
> Even fairly comparing open-source implementations is difficult enough, as=
 can
> be seen by the numerous flamings between the PostgreSQL and the MySQL cam=
p, for
> example.

Thanks to be patient,
Best regards,