[DB-SIG] Next Version [was Re: Preparing statement API]

[M.-A. Lemburg]

Stuart 'Zen' Bishop wrote:
> 
> On Sun, 30 Jan 2000, M.-A. Lemburg wrote:
> 
> > Quoting is generally not needed since you pass in the data
> > via bound parameters. The DB interface does the needed quoting
> > (if any) without user intervention.
> 
> I have largish Perl program that couldn't function without it - sort of
> a command line data miner. Now that I think of it, it probably could have
> been written using named parameters (rather than positional - what generic
> PerlDBI supports). It would still be nice to access this though (eg. a GUI
> SQL query builder or DBA tool that needs to be able to show the generated
> HTML). Every DA needs the code, so it would be nice to access it :-)

I'm not sure what you would do with a quoting method... it is
usually only needed in case you want to pass raw data to the DB
embedded in the SQL command you post and this is already nicely
dealt with in the .execute() method through the use of bound
parameters.

Perhaps I'm missing something obvious ?
 
> > >     con.autocommit(1)
> > >     mode = con.autocommit()
> > >
> > >         As discussed above. An interesting point from the docs - 'Drivers
> > >         should always default to AutoCommit mode. (An unfortunate choice
> > >         forced on the DBI by ODBC and JDBC conventions.)'. I see no
> > >         reason why we can't do it properly :-)
> >
> > See above... all drivers should default to auto-commit mode
> > being *disabled*.
> 
> Yes - properly :-) Death to MySQL! *duck*.

MySQL was created as a read-only database -- where you typically
don't need transactions ;-)

Seriously, the above is of course only applicable to data
sources providing transactions. If they don't you wouldn't
want to use them for critical applications and instead go
with one of the largish DBs, e.g. Oracle, DB2, etc.

> > Not sure what you're talking about here... what issues were there ?
> 
> I'm not sure either :-) I seem to remember some discussion about transaction
> starts, but I can't find it in the archives :-( It is either FUD, an
> overactive imagination on my part, or relates to the following from
> http://www.zope.org/Members/petrilli/DARoadmap :
> 
>     self._begin - This is called at the beginning of every transaction.
>     Depending on your database, and its implementation of "implicit
>     transactions", you may or may not have to do anything here besides a
>     pass.
> 
> If the PyDB API states that a new transaction is implicitly started on
> connection, rollback or commit, or the first executable command afterwards,
> then self._begin in a ZopeDA->PyDB adaptor can just be 'pass'. This
> might be part of the SQL spec - I'm not sure.

Not sure about the SQL spec, but ODBC clearly states that a
transaction is implictely started when the cursor is created.
 
> I can't think of any databases I've dealt with that self._begin would
> be needed. Can anyone think of situations where it *is* needed? I think
> ZopeDA's need the call, as they are designed to support non-SQL databases
> as well such as IMAP, LDAP, plain text, ad infinitum.

Those examples don't support transactions and thus wouldn't need
the ._begin() call anyways ;-) I think the ._begin() method
is an abstraction in the DA layer to initialize a cursor and
not necessarily related to starting a transaction... could
be wrong though.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/