Re: pysqlite design decisions

On 4 Dec, 10:12 am, [email protected] wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>glyph-TyWPi3/[email protected] wrote:
>| 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.
>
>I don't see the big difference between saving one string vs saving one
>statement that is the prepared result of the string.  Since the
>concatenation is the work, you are only doing it once either way.

It is definitely an isomorphic translation for _any_ API to go from 

    foo = SomeObject('random strinct with instructions in it')
    foo.api_function()

to

    foo = 'random string with instructions in it'
    api_function(foo)

The differences are subtle, but I find that using custom types to refer to different types of strings prevents all kinds of errors.  SQL is a string, HTML is a string - heck, even PNG data is a string before it's parsed as an image.  I've long stopped being surprised when I see one of these ending up in the wrong place.

>| 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.
>
>In that case I will provide the option for the Connection to close all
>the cursors :-)

Great.  Having 'commit()' mean 'commit ... some time in the future, depending on what other method I call' is just nasty.

Another nice behavior would be to allow commit(), in the state where the transaction would not actually be committed, to roll back the transaction and raise an error.

>| The percentage of development effort given to maintenance as opposed to
>| initial development approaches 100% as T approaches infinity :).
>
>There are cases where that isn't true especially if you are sitting on
>top of other layers.
>
>drh does not expect there to ever be a SQLite 4.  The vast majority of
>changes are expected to be in the SQL which is transparent to apsw since
>I don't care what it is.  Since writing the initial version of apsw, I
>haven't changed the core as the core API of SQLite has not changed, with
>the exception of the Python 2.5 64 bit changes.

There is _always_ more to do.  For example, the website suggests that SQLite is inappropriate for usage on servers.  I disagree - I've found SQLite to be a _great_ server-side database.  It's so easy to segment your data into manageable chunks, to create new databases on the fly, to migrate them around... for certain high-volume server applications where the application is managing its own cluster, it beats certain "enterprise database" systems hands down.

Of course, this usage _would_ be even better if it had a few more features :).

>I think that having an initial test suite is probably the first thing
>that is needed.

It is so nice to hear someone else saying this for a change :).  Tests are a requirement for Divmod or Twisted to accept any patch, and I end up spending a fair amount of time arguing with people about the requirement:

    http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem

>That way underlying code can be re-engineered and
>breakages detected.  That is one reason drh like his test suite - he
>doesn't have to be too nervous about changing and refactoring code, or
>adding new features.

Can I get an AMEN!  Hallelujah!

>Is there a DBAPI test suite available?

Some trivial googling reveals this:

   http://stuartbishop.net/Software/DBAPI20TestSuite/

I've never used it though.

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