Re: pysqlite design decisions

On 09:56 am, [email protected] wrote:

>glyph-TyWPi3/[email protected] wrote:
>| The more sqlite-like semantics were handy, but the fact
>| that strings would randomly come back as 8-bit or unicode depending on
>| their contents was annoying :-\.
>
>They should only ever come back as 8 bit if they are pure ASCII (ie
>7bit).  How did this cause any problems?  It was intentional this way so
>that simple apps that only ever used ASCII only ever had ASCII.

Axiom explicitly forbids use of str objects to represent text anywhere.  You get unicode back from text fields, you get str objects back from blob fields.

If you let your application APIs mix str and unicode freely, then there's no way to debug transcoding bugs.  You get some string like "foo-b2o" and you think, "oh how nice, ASCII, no need to encode that", but actually it's u'foo\N{ETHIOPIC SYLLABLE SEE}' encoded with punycode.

The size optimization that you get from switching from unicode to str objects really ought to be an implementation detail of the unicode type implementation.

>To achieve that drh has special filesystem code that fakes disk fulls,
>power being pulled etc.  Sadly we can't get Python to randomly fail.

Getting Python's internal test coverage up to a decent level would be a time-consuming project, and a bit out of scope for this discussion.  Still, I wish somebody would do it - I'm really happy to hear that drh has put that much thought into testing.

>| Keep it locked on the GIL?
>
>That would happen as a side effect anyway.  I just got very nervous when
>considering doing the same thing for apsw.  The combinations of when
>destructors run, invalidation etc can leave loopholes unless you are
>very diligent.

Threads are always scary.  Pretty much any threaded code that involves locked, shared data structures is going to be impossible to test thoroughly - you can call any function at any point from any other function... you have to reason really hard about where everything's going to happen.

The statement cache doesn't strike me as especially scary for any reason though.

>| I've heard, sqlite itself is only middling good at dealing with multiple
>| threads.

>You heard wrong.

The impression may simply have been garnered from the proximity of threading bugs to database bugs in extremely poorly tested projects such as Trac.

>My personal opinion is that DBAPI is a crock.

This opinion seems really common.  Is there a DB-API 3.0 in the works that fixes some of the more obvious issues?

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