On 12 Sep 2006 10:24:00 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list