Is it just me, or is Sqlite3 goofy?

[mensanator at aol.com]

Mike Owens wrote:
> On 11 Sep 2006 23:29:28 -0700, mensanator at aol.com <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.
>
> Implying? There's a solid word. Migrating data from SQLite to other
> databases is no more difficult or easy than migrating data to any
> other database. Do you think this is ever trivial? It's as hard or as
> easy as you make it. No database can just take any schema and the data
> you put in it and just magically convert that schema/data to
> flawlessly work in any arbitrary database of your choosing. Some
> databases have tools to help with this, but they still are not
> perfect.

So, knowing that, would you agree that

<quote Python Library Reference 13.13>
If switching to a larger database such as PostgreSQL or Oracle
is later necessary, the switch should be relatively easy.
</quote>

is misleading if not outright untruthful?

>
> > 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.
>
> Lying? Whose lying?

See above quote. And while you're at it, see the sqlite docs
about how the SQL Language Specification of static typing
is a bug.

> Where on the website is there a lie about
> anything? From what I can tell, you've not taken the time to read the
> documentation or post anything to the mailing list. You've just posted
> jeremiads on the Python list.
>
> Don't like the documentation?

No, it's misleading and full of errors (this is the Python docs
I'm referring to).

> Ever volunteered to help out?

That's what this thread was about, testing the waters.
No point making bug reports if I'm the one who's wrong.
But it turns out I'm not wrong, sqlite IS goofy and this
should be pointed out.

> Ever posted any suggestions on the list or report a bug?

I'm still considering it. This thread has been very useful
towards that.

> Do you really
> think that open source projects exists to serve you and meet your
> standards? Do you think that free code and documentation just falls
> like manna from heaven?

But why does it have to be wrong? It's just as easy to get
things right. Isn't that your complaint, that if I read the sqlite
docs first, the riculous examples in the Python docs would
have made more sense? Why didn't the guy writing the Python
docs read the sqlite docs first?

> Do you honestly think the two core developers
> of SQLite have some secret agenda to deceive you or the world into
> using SQLite?

Why do they claim that the SQL Language Specification of
static typing is a bug? That's simply a lie. Why do they claim
they've "fixed" it in a backwards compatible way? That's another
lie.

Why didn't they simply say they have an alternative to static
typing? Because part of the deception is to make people think
there is something wrong with static typing.

>
> > > Of course you could restrict yourself
> > > to, by example, SQL92 entry level and be a lot more compatible.
> > > But if I'm using a nice OO language like Python which lets me bind
> > > *any* object to *any* name, why should be wrong to bind *any* object
> > > to *any* database column?
> >
> > But SQL isn't OO, it's relational. That means JOINing tables
> > together on a common field. In theory, due to the comparison
> > hierarchy, it is impossible to do JOINs with dynamic typing
> > since different types can never be equal. In practice, the type
> > affinity kluge trys to work around this but can't do anything
> > if the string doesn't look like an integer when a text field
> > attempts to JOIN to an interger field.
>
> Unless you ensure that the correct types are put int the column to
> begin with, which is entirely possible with SQLite, as I've already
> demonstrated. And if that's just too much to bear, you can still do an
> inner join by explicitly casting the two columns in the join
> constraint to a common desired type. Want to know how? Read the
> documentation.

And what do you get when you implement all these kluges?
A database that effectively is static typed. Do you still think
static typing is a bug?