On Sun, Apr 2, 2017 at 3:50 PM, David Burgess <dburg...@gmail.com> wrote:
> I preferred the pre 3.18 behaviour. More flexible and fulfills a real > world requirement. The pre-3.18 behavior made it impossible to have the CHECK constraints checked. So I don't view that as "more flexible". If you bothered adding a CHECK constraint, for integrity, and given that SQLite allows to disable the CHECK constraint on a per-connection basis, don't you think it's important to be able to validate the data is still "correct" as per the *declarative* "rules" in effect? This also mirrors what is available for foreign keys, so more logical, FWIW. I disagree with Simon recommendation of using a TRIGGER instead. CHECK constraints are about integrity. TRIGGERs are not. If you have integrity rules that evolve with time, you either 1) update the old now-non-conforming data to follow the new rules; or 2) update the rules to allow both the old and the new format/rules for old and new data. Sure #2 may force you to recreate the table, since SQLite a little ALTER TABLE/COLUMN support, but rules typically change much less often that data does. New integrity rules *is* schema evolution, despite column names and types not changing. CHECK constraints for new a filter for new insertions, they are declarative *integrity rules*. --DD _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
