> I believe I understand Darren's point (whether or not I care for them > is another story).
Yes, you've understood Darren for the most part, but clearly don't understand the objections. > On Fri, Oct 30, 2009 at 2:22 AM, Roger Binns <rog...@rogerbinns.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Darren Duncan wrote: > >> But on a newer SQLite that implements the stronger typing support I > >> proposed, > >> when that feature is active then columns with declared types like > >> INTEGER/etc > >> would enforce that only values of that type are stored there, > > > > I might have misunderstood you. Do you really mean that a new SQLite > > version should enforce the types with 'UNIVERSAL' meaning any? Do you > > really expect everyone to have to upgrade their database schemas for this? > > No, (I think what) Darren is saying is that a column with type > UNIVERSAL will behave as if that column had no CHECKs at all. It would > not enforce any type, and behave, more or less, like any SQLite column > except for INTEGER PRIMARY KEY currently behaves. That is, UNIVERSAL > would allow storing anything in it. You said no, then answered yes. This proposal would require many thousands of existing schemas to be updated. Anyone who doesn't want the strong typing would have to update their schema to use the "UNIVERSAL" keyword. This isn't going to be acceptable to ANYBODY except the "strong typing" clan. Additionally, this would be quite the shock to users not participating in this thread, who may, without prior warning, see new random errors when they update. A likely sore spot is the TIMESTAMP which, due to the current lack of documentation and supporting APIs, may likely be used to store data in ANY of the 4 types right now. > > > >> shorthand for an appropriate CHECK constraint, > > > > Now I am even more confused. There is this alleged group of people out > > there who need type enforcing but are somehow unable to put in CHECK > > constraints (which also let you addition stuff like range checks and other > > restrictions on values), so the rest of us would have to start littering our > > schemas with 'UNIVERSAL' to cater for them? > > Any column not declared as UNIVERSAL, so, INTEGER, REAL, BLOB, TEXT, > perhaps even a new type called DATETIME, would behave as if CHECK > CONSTRAINT were defined on them, allowing only the declared type of > data to be stored in them. Fortunately, I don't think this is exactly what is being proposed. The proposal (as I read it) only does the strong type checking on column types it recognizes, and others are left to the current model. If strong typing were done on any column not declared as UNIVERSAL, this would wreck even more schemas, since there are certainly going to be countless schemas using data types other than those that would be implemented. SQLite currently takes *ANYTHING* as the typename. This means, for example, someone might choose to give each column a type based on the C/C++ type/class that they will use to manipulate it. Not good SQL, but functional SQLite and plenty clean. I personally use TIMESTAMP for what you called DATETIME and there are who knows how many different variations on that, used by other SQL engines. > I see no problem with the existing tools, but, on the other hand, I > really see no problem with Darren's suggestion as well other than it > might make SQLite less Lite and more Heavy. > > But, I certainly see no backward compatibility issues with Darren's > suggestion. His suggestion allows those who care for strong typing, > but are too lazy to do it themselves, will actually have it done for > them, and those who don't care for strong typing can use UNIVERSAL. This IS a backwards compatibility issue. People get the new version of the library, but it behaves substantially differently than the previous version. The behavioral difference may break their app, and worse, it will not break at compile time, but only at runtime. This is a backwards compatibility sort of the worst type. Worse yet, this could affect users more transparently than you think. Take, for example, the web site written in PHP that uses SQLite. One day PHP is updated to use the new strongly typed SQLite, then Apache is updated to use the latest PHP, finally, one by one, web hosting providers throughout the world update to the latest Apache. And a whole rash of websites suddenly have problems. These sites changed NOTHING, but suddenly their sites don't work? I see SERIOUS problems with this proposal, especially in terms of backwards compatibility. John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
