[DBD-SQLite] Removing the on-by-default referential integrity.

[Darren Duncan]

Adam Kennedy wrote:
> For the first production release of DBD::SQLite with foreign keys,
> it's starting to make me nervous that we will enable it by default.
> 
> As things currently stand, nobody that is using SQLite has ever seen
> this feature before. They haven't had the chance to work with it at
> all before we shove it down their throats.
> 
> I think I'd like to follow SQLite itself for now and default it off.
> 
> Thoughts?

Doing what you say would follow the policy of SQLite itself.  I believe they are 
also strongly considering turning it on by default within the near future.

For DBD::SQLite, I have a few thoughts.

1.  DBD::SQLite serves a smaller ecosystem than SQLite itself, and I think it is 
safer for us to sooner push through changes like having foreign keys enforcement 
enabled by default.

2.  Having foreign keys enabled by default would only affect people that are 
explicitly writing foreign key constraints into their SQL.  So in general, why 
would people write those constraints but not expect them to be enforced?  Maybe 
for documentation purposes, but in that case presumably they also had other 
means to keep their data clean, and if enforcing foreign keys becomes active 
that should not cause an immediate break if their replacement practices were 
doing their job.

3.  I would support foreign key enforcement being turned off by default only if 
we make it very clear that the disabled-by-default state is meant only to be 
temporary and transitional, and that DBD::SQLite will have the feature enabled 
by default within a certain time frame, such as within 2 months, or alternately: 
  Make the public release 1.27 have foreign keys disabled by default, and have 
the very next public release (and all developer releases) have it enabled by 
default; they only exception is if another public release has to go out very 
soon to fix a critical bug, in which case it goes out with say a disabled 1.28, 
and then the same policy stands otherwise.

So essentially, just 1 disabled-by-default stable release is fine, so people who 
expect to be able to write foreign key constraints that aren't enforced can get 
the bug fixes we have to date, and aren't forced to have one to get the other; 
however, enabled-by-default should be the default thereafter.

I see an advantage of disabled-by-default if we want to have a test suite for 
the feature added, and you want to ship a stable 1.27 right now.

-- Darren Duncan