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

[Marcos Sánchez Provencio]

I understand that you mean that the only clear mode to specify is by
writing the actual Python code... I prefer strict specs and sample code.

El mar, 18-02-2003 a las 21:47, Anthony Tuininga escribió:
> 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 = __import__(driver)
>         self.rawConnection = self.driver(**args)
> 
>     def cursor(self):
>         return Cursor(self)
> 
>     def commit(self):
>         self.rawConnection.commit()
> 
>     ETC
> 
> 
> class Cursor:
> 
>     def __init__(self, connection):
>         self.connection = connection
>         self.rawCursor = connection.rawConnection.cursor()
>         self.statement = None  # or whatever the name ought to be
> 
>     def prepare(self, statement):
>         if hasattr(self.rawCursor, "prepare"):
>             self.rawCursor.prepare(statement)
>             self.statement = 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ánchez Provencio wrote:
> > El mar, 18-02-2003 a las 15:51, Anthony Tuininga escribió:
> > > On Tue, 2003-02-18 at 06:44, Marcos Sánchez Provencio wrote:
> > > > I was thinking more about vampirising (?) mx.ODBC extensions API an=
d
> > > > using them as an API specification. Even M.-A. has proposed that so=
me
> > > > time, I think.
> > > > 
> > > > I am not sure we need yet-another-layer. The minimal to get whateve=
r 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 slightl=
y
> > > 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 t=
he
> > > standard). Personally, I would prefer once.... :-)
> > 
> > What is the magical way to write it once?
> -- 
> Anthony Tuininga
> anthony@computronix.com
>  
> 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
> 
> 
> _______________________________________________
> DB-SIG maillist  -  DB-SIG@python.org
> http://mail.python.org/mailman/listinfo/db-sig