Mike Owens wrote: > On 9/11/06, Steve Holden <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list