[DB-SIG] spec: named parameters: clarification needed

[Anthony Tuininga]

On Tue, 2003-02-18 at 06:44, Marcos S=E1nchez Provencio wrote:
> I was thinking more about vampirising (?) mx.ODBC extensions API and
> using them as an API specification. Even M.-A. has proposed that some
> time, I think.
>=20
> I am not sure we need yet-another-layer. The minimal to get whatever the
> RDBMS gives us to Python DBAPI is enough for me. That is, after we
> clarify parameter passing and schema funtions ;-)

But therein lies the problem. Every database vendor does this slightly
differently. There is going to __have__ to be a layer in between the
database and the Python DB API standard -- either it will be written
once (a common layer) or many times (a layer written by each driver
developer excepting those who write for database vendors that mimic the
standard). Personally, I would prefer once.... :-)

> El mar, 18 de 02 de 2003 a las 14:07, Magnus Lycka escribi=F3:
> > M.-A. Lemburg wrote:
> > >ODBC was designed to make dealing with multiple database backends
> > >in a more or less consistent way. To find out how far you can go,
> > >have a look at the ODBC spec. Believe me, the Python DB API is
> > >like first day in school compared to a Ph.D. class. mxODBC does
> > >all the hard work for you here, so there's no need to worry about
> > >how ODBC works when coding in Python.
> >=20
> > Considering the technical state of ODBC and mxODBC today, I think
> > that it would be great if that would be the standard path for
> > database access in Python applications today.
> >=20
> > Unfortunately, mxODBC is neither the standard for Python database
> > interfaces, nor an open source product. Ok, it's free in
> non-commercial
> > applications, but it's definitely not GPL compatible, nor compatible
> > with the Python License.
> >=20
> > This is not meant to criticize Marc-Andr=E9 in any way, but it *is*
> > an obstacle for making OBDC a standard in Python. Considering the
> > awakening interest in the EU for open source software (e.g. the
> Swedish
> > agency responsible for public procurements published a very OSS
> positive
> > report with some mentioning of python recently) I should perhaps try
> to
> > convince my politicians to spend some EU funds on sponsoring an open
> > source mxODBC! (I guess M-A wouldn't mind a licence change if the
> price
> > was right? ;)
> >=20
> > A more boring option would be to make a python wrapper for wxODBC,
> > http://www.wxwindows.org/manuals/2.4.0/wx497.htm
> >=20
> > For the "heavy" developers on this list, who are building big products
> > from scratch, this might not matter, but for the "ordinary" python
> > users, who mainly use the works of others, the current situation IS a
> > problem.
> >=20
> > There are plenty of freely available python applications today
> > that talk to SQL databases, usually MySQL or PostgreSQL, sometimes
> > to two or three different databases. It would be a big win if it
> > was possible for a python user to download several different database
> > frontends without having to install, configure and administer MySQL
> > and PosgreSQL as well if he already has a running MS SQL Server,
> Oracle
> > or SapDB installation...
> >=20
> > I'm sure such a possibility would also lead to more users of these
> > applications, which would lead to further development and so on.
> >=20
> > I realize that it's completely possible to limit oneself to a certain
> > database with a generic package like ODBC, by using features that
> aren't
> > available in all databases, but today, especially due to the different
> > parameter styles, it's impossible to write generic code in a
> standardized
> > way, since the standard doesn't include a common denominator.
> >=20
> > What ever the solution will be: ODBC for all, a standard layer on top
> of
> > DB-API, or something completely different, I think I will be happy if
> > it becomes widely adopted, but it's boring if every project will have
> > to reinvent the generic approach. This is certainly an area that I
> feel
> > should have a standard approach.
> --=20
> gpg --recv-keys --keyserver wwwkeys.pgp.net B9AD9B1B
--=20
Anthony Tuininga
anthony@computronix.com
=20
Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada  T5N 4A3
Phone:	(780) 454-3700
Fax:	(780) 454-3838
http://www.computronix.com