Been watching this discussion go back and forth, and I'd like to weigh in. I'm generally a HUGE fan of strong typing, but this doesn't do it for me. To me, strongly typed means a compiler catches my type mismatches before the app goes out the door. In this case though, no matter what you do, a mistake with your use of a type can never show up at compile time. You'll only get the error at runtime.
Frankly, once the mistake is made, and the code deployed, I expect the program to behave the best it possibly can. Making the application blow up, rather than storing the data and moving on, is not a great plan in my mind. The user doesn't *care* that a REAL was provided, but an INTEGER was expected. The user cares that the app exploded on them and didn't save the edit they just made. If strong data typing *at the SQL level* is that important to you, this is a job for constraints: CHECK(typeof(product_id) = 'integer') If you hate the idea of manually adding these constraints, you could even write something to automatically add them for you. If you hate the performance hit, you could add them only in your debug build. As far as making the core universally reject data that doesn't match its belief about the format that data should be in, I think this is a very bad idea. It would break plenty of old code to provide a feature that is already possible for which the benefit is questionable anyway. Since SQLite can't catch my type errors at application compile time anyway, I think I like the current behavior better. Just my 2 cents. John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
