3 ms·
SQLite's quirks page [1] actually suggests the same thing: > In retrospect, perhaps it would have been better if SQLite had merely implemented an ANY datatype
by scottlamb 7y ago
SQLite's quirks page [1] actually suggests the same thing:
> In retrospect, perhaps it would have been better if SQLite had merely implemented an ANY datatype so that developers could explicitly state when they wanted to use flexible typing, rather than making flexible typing the default. But that is not something that can be changed now without breaking the millions of applications and trillions of database files that already use SQLite's flexible typing feature.
I wish they had done this in the first place. I wish even now that they implemented a pragma to enforce types (and introduce the ANY type for folks who explicitly want it). But SQLite has enough good things going for it that I'm happy to use it in spite of this problem.
[1] https://www.sqlite.org/quirks.html https://www.sqlite.org/quirks.html
- nine_k 7y agoI don't see why this must be a breaking change. (1) Add a flag when opening a database to show that you want data types enforced. (2) Add code to all the input pathways to check for type compliance. This way a database with correct data types will stay correct. (3) Do not change anything in the storage layer. What am I missing?
- murftown 7y agoSeems like (1) is doable, as long as it's opt-in. But if it becomes the default behavior, existing applications would break when they do something against the type system. I'm not sure what (2) buys you.
- nine_k 7y ago(1) is the interface to trigger (2).
- scottlamb 7y agoThis is very similar to what they did for foreign key support. https://www.sqlite.org/pragma.html#pragma_foreign_keys https://www.sqlite.org/pragma.html#pragma_foreign_keys