Is it just me, or is Sqlite3 goofy?

Steve Holden steve at holdenweb.com
Mon Sep 11 23:10:47 EDT 2006


Mike Owens wrote:
> On 9/11/06, Steve Holden <steve at holdenweb.com> wrote:
> 
> 
>>>Furthermore, I'm not responding to Python's representation of one
>>>thing or another. I am responding to some of the ridiculous and unfair
>>>criticisms directed at SQLite. Whatever Python did or didn't do, or
>>>whatever PySQLite does or doesn't do, SQLite doesn't deserve to be
>>>drug through the mud.
>>>
>>
>>Which is precisely why I took pains to acknowledge that there were many
>>purposes for which SQLite is entirely suitable.
> 
> 
> Which was objective and diplomatic. Thanks.
> 
Well known for my even temper and cool objective thinking.
My modesty, too ;-)

> 
>>>>You shouldn't need to
>>>>add check constraints to verify that the value stored in an integer
>>>>column is actually an integer.
>>>
>>>You should if your using SQLite, and this is clearly documented:
>>>http://www.sqlite.org/datatype3.html.
>>>
>>
>>Right. In which case, why bother to define the types of the columns in
>>your table declarations?
> 
> 
> Actually there is some use for this, so long as the declared types
> correspond to one of SQLite's storage classes -- INTEGER, REAL, TEXT,
> BLOB, or NONE. When SQLite sees one of these as the declared type, it
> will apply some "affinity" rules for updates/inserts which will
> attempt to coerce the input value to that type if possible. So while
> this does not give you true strict typing, it does provide you with
> something helpful if you code your application with this in mind. As
> already mentioned, you will need triggers or check constraints if you
> need true strict typing.
> 
> 
>>>Then what does calling it crappy and goofy suggest?
>>
>>That colloquial English expression is acceptable on this list.
> 
> 
> And what about some of the other colloquial expressions I saw but didn't repeat?
> 
Well, I'm not going to take responsibility for others' immoderate 
comments, am I? But remember that this is usenet, where generally you 
can count on somewhere between 20% and 80% of what you read being 
somewhere between ill-informed and downright wrong. This group seems to 
have a better record than most, but that just means less crap, not no 
crap ...
> 
>>Strict affinity mode seems to represent a movement towards more rigorous
>>type checking. So the designers of SQLIte accept that it wasn't perfect.
>>So what? Please, don't take on so. It's only ones and zeroes.
> 
> 
> This is an example of SQLite listening and responding to constructive
> feedback. When I first started using SQLite, it didn't have an
> autoincrement primary key. I made a case for it, asked nicely, and it
> was done in three days. Most people will agree that this approach
> tends to work better in most projects, as opposed to calling them
> goofy and crappy, or its author a crackpot.
> 
Works better for Python too. Anyway, you seem to be feeling better now, 
so I presume getting it off your chest helped :-)

SQLite will clearly fare well in the future with a responsive 
development team like that.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden




More information about the Python-list mailing list