Re: pysqlite design decisions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

glyph-TyWPi3/[email protected] wrote:
| Just a thought: one way to do this would be to simply have a
| (cursor/connection).prepare() method, which returns an object that can
| be used interchangeably with a string passed to "execute".

The model for this would be compile() and exec/eval in Python core.

However I am somewhat skeptical of exposing these compiled methods.  Do
they really make that much of a performance difference to you?  My
expectation is that if they become necessary then they will be added to
the SQLite core itself transparently, just like the various regular
expression libraries do.

| Still, that API is a very nice idea.  One of the scariest features of
| sqlite (not pysqlite) is that leaving a cursor from a SELECT open with
| unclaimed results will effectively delay a COMMIT forever...

You also can't close the containing database object at the SQLite level
either.  I am about to add close() methods to apsw because of Python 2.5
lazy finalization means any amount of time can lapse between the final
reference being dropped and the GC running.  Something I am considering
is having the ability for the Connection close method to go off and
close all stray cursors.

| Huh, that looks a lot more complicated and specific than what I want.  I
| would just like to be able to specify a python callable that gets called
| with a 2-tuple of (sql, args) each time a statement was executed.  (or
| really, (statement, args), if there were statement objects).

http://www.rogerbinns.com/apsw.html#tracers    :-)

| This is not a -0, this is a +10000!!!!  :-D  I would *LOVE* to see APSW
| and pysqlite merge, even at the very basic level of just being in the
| same repository.  This would eliminate confusion for people wondering
| which binding to download, and could eventually lead to a big reduction
| in duplicated effort.  From my point of view this would be the _best
| possible_ way to expose the lower layer, get all bug reports going to
| the same place, etc etc.

Currently APSW has no formal place on the net.  I use the Subversion
repository of BitPim (apsw was originally written for BitPim), the
BitPim SourceForge for downloads and my personal site for the web pages.
~ There is no mailing list.  There aren't any bugs either :-)

I am totally happy for APSW to be hosted with pysqlite.  Someone else
will need to work out things like should there be separate trac instance
or the same, shared or the same Subversion etc.

As for the duplication of effort, that has already been done (sunk
cost).  I can certainly see a layer of Python code on top to do silly
transaction semantics required by DBAPI as well as pretending that
SQLite has more than 5 types.

My future plans are to track updates in SQLite in a timely manner,
remain as entirely C code, and to keep improving the testing.  I also
make no attempt to support older versions of SQLite.  ie there is no
SQLite version dependent code.

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

iD8DBQFFc5PQmOOfHg372QQRArUsAJ945pJzJFORtGFMB4cRRAuxXohr3gCgtgtt
ONKaeoYBimTRC68xgyvqOYc=
=XHft
-----END PGP SIGNATURE-----