Is it just me, or is Sqlite3 goofy?

[Mike Owens]

On 12 Sep 2006 10:24:00 -0700, mensanator at aol.com <mensanator at aol.com> wrote:

> 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?

Not in the least.

If you know what you are doing from a database perspective (not just a
SQLite perspective), migrating data to another database is exactly
that -- relatively easy. That means, you may have to recreate or
modify your schema for the target database -- and this is true in ALL
databases. Native datatypes vary from system to system, and some
systems support user-defined data types, in which case your schema
will definitely have to be modified. How would you migrate a CIDR type
in PostgreSQL to a numeric field in Oracle? You have to work at it.

Next, as far as transferring you data, you most likely have to resort
to some delimited format, or INSERT statements, which is no different
than any other database.

So,  I would call that relatively easy without a stretch, and
certainly no different than migrating data with any other database.

Really, how is this different than migrating data to/from any other database?

> > > 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.

Both of which have been addressed in detail. The above quote is not
even stretching the truth, and the latter fact is a deviation that
SQLite has every right to make because they, and not you, wrote the
software. Furthermore, it is very clearly stated on the website.

So how is that a lie?

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

I didn't join this thread because of Python's documentation, and I've
made that clear. I am here because you are unjustly vilifying the
SQLite project.

> > 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.

Then be a man and point it out on the SQLite mailing list, where you
can be called on it, rather than ranting about it here.

> 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?

First, SQLite's approach is no more wrong than any other database's
deviation from the standard. Second, as I've said, I'm not here for
the Python issues. I think they'll get things sorted out in due time,
and people on this list have been very receptive to your feedback.

> > 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.

It's not a lie at all. Are you incapable of comprehending the context
of that text? Do you not understand that it effectively says "This is
the way we do things. It's not in agreement with the SQL standard. We
know that, we are doing it this way, and here's how it works, take it
or leave it." And the whole bug in the SQL standard, if you can't
tell, is called humor.

> Why didn't they simply say they have an alternative to static
> typing?

They did. You couldn't understand that from the documentation?

> Because part of the deception is to make people think
> there is something wrong with static typing.

Yes, it's really an underhanded conspiracy designed to deceive and
mislead on a global scale. I can just see the developers sitting
around plotting:

"Hey, let's write some free software. Yeah let's give the code away
for free and not make a dime from it. Yeah, and then let's make up a
bunch of lies to make people want to use it, so we can continue to not
make a dime from it. And let's slander the SQL standard, and say all
sorts nasty things about it. Yeah, that's how we'll spend our nights
and weekends."

You really need to find some fault that will stick at this point, don't you?

They're really up to something.

> And what do you get when you implement all these kluges?
> A database that effectively is static typed.

Only if you want one. Otherwise, you have the freedom of dynamic
typing, which other databases don't afford. So, you in fact have more
freedom than you do than with databases that only offer strict typing.

> Do you still think static typing is a bug?

Did I say this, ever? I am not the SQLite website.

I don't think either is a bug. Both are two different viewpoints used
to solve a particular problem. Dynamic typing and type affinity can be
incredibly useful, especially for prototyping and scripting languages.
I don't have to dump and reload my tables if I want to change a column
I am testing out. I just delete me data, reload it, and get my program
to store a different representation in the column. And when I need
strict typing, I simply declare a check constraint. So no, you can't
say that your particular need for static typing meets all criteria for
all developers using SQLite. And frankly, if SQLite doesn't meet my
requirements, rather than badmouthing SQLite, I use another database,
such as PostgreSQL.

And they are entirely correct in saying that you are provided the
facilities to implement strict typing. You are given five native
storage classes and the means to ensure that only data of those
classes is stored in columns. What's all the fuss?

Again, SQLite is completely up front about its approach to typing. I
still don't see how is it that anyone is lying to you.