Is it just me, or is Sqlite3 goofy?

[MonkeeSage]

mensanator at aol.com wrote:
> But it was stated in the sqlite docs that ALL SQL databases
> use static types implying that sqlite will be incompatible
> with any "heavy" database should the need arise to migrate
> upwards. The issue is not that there will be compatibilty
> problems with any data migration but that the truth is exactly
> opposite of what's claimed in Section 13.13.
>
> I'm not saying sqlite can't be used, what I'm asking for
> is that the documentation lay the facts out and I'll decide
> whether I can make this work in my application. Lying about
> it makes you sound like Microsoft.

I thought your qualm was with the pysqlite docs, not the sqlite docs
(which apparently do make it plain how the database handles typing)?

Also, as others have mentioned, there are a number of ways to ensure
type safety, as long as you know how the database works (which as I
understand was your original point -- that it should be better
documented how it works in the pysqlite docs; and I am inclined to
agree -- at least a mention with link to the sqlite docs would be
helpful). But given that type safety is not an issue if you use those
ways of ensuring it, then the move to a fuller database _will_ be
relatively easy. If you don't want to change anything in your database
creation/update code ala check constraints, you can always explicitly
validate from python, which can be done programatically (very simple
example -- you could also use regexp patterns to validate; e.g., string
fields not only must be type str, but must not match '^\d+$', &c):

rows = [
['1', 'fred', '0051', '/home/fred'],
['2', 'bob', '0054', '/home/bob'],
['3', 'bork', '>056', '/home/bork']
]
def validate(row):
  return [int(row[0]), str(row[1]), int(row[2]), str(row[3])]
for i in xrange(len(rows)):
  rows[i] = validate(rows[i]) # <- throws an exception on the third row
  # database stuff here...

Regards,
Jordan