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

[Anthony Tuininga]

You write one module which accepts plugins (the existing drivers). These
drivers must accept requests in a defined way (the API between the
common module and the driver modules). The common module would handle
the interface to the end user and the driver module would handle the
interface to the database. The common module might look something like
this (to start with):

class Connection:

    def __init__(self, driver, **args):
        self.driver =3D __import__(driver)
        self.rawConnection =3D self.driver(**args)

    def cursor(self):
        return Cursor(self)

    def commit(self):
        self.rawConnection.commit()

    ETC


class Cursor:

    def __init__(self, connection):
        self.connection =3D connection
        self.rawCursor =3D connection.rawConnection.cursor()
        self.statement =3D None  # or whatever the name ought to be

    def prepare(self, statement):
        if hasattr(self.rawCursor, "prepare"):
            self.rawCursor.prepare(statement)
            self.statement =3D statement

    def execute(self, statement, *args, **kwargs):
        if self.statement is not statement:
            self.prepare(statement)
        self.rawCursor.execute(statement, args or kwargs)

    ETC.

def connect(driver, **args):
    return Connection(driver, **args)


This is rather rough. The execute method would have to handle converting
arguments and the SQL passed in so that two methods only would be used
for passing argument: via a sequence, or via keywords (or whatever was
agreed to by the group).

Does that help answer the question or did that raise more questions? And
if anyone asks why -- it is to define the interface clearly and allow
for common code to be truly common, rather than have each driver author
have to write this code over and over again. You might claim that this
has already been done via the DB API spec -- but I would say that words
are inherently ambiguous and subject to misinterpretation and programs
must by definition be unambiguous or a computer will complain rather
strongly about it... :-) Since it is Python code, referencing the
rawCursor and rawConnection attributes would be possible for those who
really needed to make use of driver specific features.

On Tue, 2003-02-18 at 12:39, Marcos S=E1nchez Provencio wrote:
> El mar, 18-02-2003 a las 15:51, Anthony Tuininga escribi=F3:
> > 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 ;-)
> >=20
> > 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.... :-)
>=20
> What is the magical way to write it once?
--=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