Re: pysqlite design decisions

On 03:19 am, [email protected] wrote:
>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.

As I said before, it's not the performance difference that concerns me most.  It's that I want to keep the object around (and yes, re-concatenating all thoses strings together to re-create the statement _is_ a significant cost), and I would rather it be the appropriate type that actually supports the operation that I need than a string.

>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.

Axiom does this by just forcing every cursor to run to completion all the time, but that's not a good solution.  I'd prefer what you are describing quite a bit.

>| 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    :-)

Exactly :)

>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.

Great!  Personally I would prefer sharing everything, to facilitate eventual sharing of code as well.  Not my call though ;).

>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.

The percentage of development effort given to maintenance as opposed to initial development approaches 100% as T approaches infinity :).  Both apsw and pysqlite have *years* of maintenance ahead of them, if not decades.  A gradual merging could still save lots and lots of time in future releases.

>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.

This all sounds fine to me... version control can probably do an OK job of maintaining branches for earlier releases for use with earlier versions of sqlite.

_______________________________________________
pysqlite mailing list
pysqlite-IAPFreCvJWPBWskQ1e/[email protected]
http://lists.initd.org/mailman/listinfo/pysqlite