[DB-SIG] Towards a single parameter style

[Marcos Sánchez Provencio]

--=-iNUKMGZEvll0OZT3JNob
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

El lun, 17 de 02 de 2003 a las 19:29, M.-A. Lemburg escribi=F3:
> Anthony Tuininga wrote:
> > Ah yes. I should have checked first. ODBC is supported on most platform=
s
> > and there is iODBC which is an Open Source initiative since ODBC was
> > originally a solely Windows solution.
>=20
> There's also unixODBC which is another Open Source ODBC manager
> for Unix.
>=20
> > I've never had good experience
> > with ODBC and neither have any of my counterparts. ODBC works great for
> > simple boring queries but as soon as things get complex, the different
> > drivers behave differently and you can't get access (easily) to the
> > power of the database. In other words, with ODBC, pick the lowest commo=
n
> > denominator and stay there. Ugh.
>=20
> That's a myth. Current ODBC drivers provide a very complete
> set of features for pretty much every database out there.
>=20
> The only downside is that you seomtimes may have to go to the
> well-known ODBC driver vendors to get a properly coded driver
> rather than using the one that came with the database.
>=20
> Writing SQL for the different ODBC backends is another
> story, though. It's also a myth that ODBC makes this much easier;
> what sometimes helps is that you can at least query the backend for
> support of certain SQL constructs and that ODBC also defines
> a minimal SQL grammar which is binding for all drivers.
>=20
Of course, I expected Mr. Lemburg to add something the minute I
mentioned ODBC (thank you). ODBC _is_ the standard in open db access, so
I think we may get some ideas from it. I agree with M.-A. that there
should be a minimal set of fully portable instructions and some
capabilities introspection to see how further we can get. After all,
there are seriousTM applications using only standard SQL. And you can
always wrap the specific parts in stored procedures, views or whatever.
Of course, I am not suggesting that everybody uses ODBC, but if we
invent something, let it be better than what we have.

I think that with all of this effort and time we could have a Schema-api
ready by now. Now do I miss that...

> > On Mon, 2003-02-17 at 10:37, M.-A. Lemburg wrote:
> >=20
> >>Anthony Tuininga wrote:
> >>
> >>>ODBC is (I believe) not common to all platforms, right? That makes it
> >>>rather useless as a replacment for the Python DB API. Besides, the API
> >>>is considerably different, right? That would make transition quite
> >>>painful. But yes, a parsing bypass is a necessity for those cases wher=
e
> >>>the parser can't handle something.
> >>
> >>Just to correct this:
> >>
> >>ODBC is a standard which is available on Windows, Unix and Mac OS X.
> >>It takes care of whatever parameter style conversion is needed
> >>and has support for both parameter binding aware backends as well
> >>as ones which don't support this. It uses the 'qmark' parameter
> >>style, BTW.
> >>
> >>mxODBC takes care of wrapping ODBC in a DB-API compatible way
> >>and is available on Window, Unix and Mac OS X as well -- providing
> >>the same consistent interface on all these platforms.
> >>
> >>So yes, ODBC is a solution. Whether it's the right solution
> >>depends on your needs and requirements, YMMV.
--=20
gpg --recv-keys --keyserver wwwkeys.pgp.net B9AD9B1B

--=-iNUKMGZEvll0OZT3JNob
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+UfGjTwXdxLmtmxsRAk42AJ9nTmdA8tT4xbX2EGWPQbuGn78krQCfRYU+
ZibkdAUdRurYFNYepGzsGrU=
=5IhM
-----END PGP SIGNATURE-----

--=-iNUKMGZEvll0OZT3JNob--