SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)

[mensanator at aol.com]

Bruno Desthuilliers wrote:
> mensanator at aol.com wrote:
> > Probably just me. I've only been using Access and SQL Server
> > for 12 years, so I'm sure my opinions don't count for anything.
> >
>
> SQLite never pretended to be a full-blown RDBMS - just a lightweight
> simple embedded database as SQL-compliant as possible.

Ah, *you* haven't read the documentation either!

"as SQL-compliant as possible"?

ROTFLMAO!

>From SQLite Homepage
  documentation
    Available Documentation
      Distinctive Features

<quote *emphasis added*>
This page highlights some of the characteristics of SQLite
that are unusual and which make SQLite different from many
other SQL database engines.

Manifest typing

Most SQL database engines use static typing. A datatype is
associated with each column in a table and only values of
that particular datatype are allowed to be stored in that
column. SQLite relaxes this restriction by using manifest
typing.

In manifest typing, the datatype is a property of the
value itself, not of the column in which the value is
stored. SQLite thus allows the user to store any value
of any datatype into any column regardless of the declared
type of that column. (There are some exceptions to this
rule: An INTEGER PRIMARY KEY column may only store
integers. And SQLite attempts to coerce values into the
declared datatype of the column when it can.)

***********************************************************
* The SQL language specification calls for static typing. *
***********************************************************

So some people feel that the use of manifest typing is a
bug in SQLite. But the authors of SQLite feel very
strongly that this is a feature.

**********************************************************
* The authors argue that static typing is a bug in the   *
* SQL specification that SQLite has fixed in a backwards *
* compatible way.                                        *
**********************************************************
</quote>

"Fixed"? Up until now, I didn't think it was possible for
crackpot theories to be implemented in computer science.
This is absolutely the craziest thing I've ever heard.

Manifest typing doesn't work *in theory*!! Sure, through
diligent data integrity management it can be made to work
in practice. But when that's applied, guess what? All your
fields end up having the same data type anyway. Duh.

And Python's inclusion of this into the standard library
is like the AMA endorsing homeopathy. It should have
been pointed out in the Python Manuals that SQLite3 is

----> NOT <----

SQL-compliant, never will be, and true SQL-compliant code

----> CANNOT <----

be made to work in this environment. So much for
"If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy."

That does not, of course, mean I don't have a use for a light,
simple database that's part of the standard library. But I could
have saved myself a lot of wailing and gnashing of teeth if I
hadn't been lied to by the Python documentation that, like you,
has the mistaken belief that SQLite3 is SQL-compliant.

Fixing the documentation is now becoming an enormous task.

What are the chances that anything I send in as a bug report
will simply be ignored? Kind of like the Emporer's New Clothes, eh?
It would be an admission of ignorance and stupidity on the part
of the Python Development Team, wouldn't it?

> In it's category,
> it beats Access and MySQL hands down. Now if you want a real RDBMS,
> you've just failed to choose the right tool. May I suggest PostgreSQL ?
>
> (snip useless rant)
>
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb at xiludom.gro'.split('@')])"