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

[Adam Kennedy]

The foreign key support has already broken code of mine, I was using
the SQLite foreign key constraint syntax, so that ORM code generators
could detect the table relationships and generate various methods.

I really want to see at least one release where it's optional, so
there's a window of time for people to do optional upgrading, rather
than immediately forcing everything to fail.

Adam K

2009/11/3 Darren Duncan <darren at darrenduncan.net>:
> 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
>
> _______________________________________________
> DBD-SQLite mailing list
> DBD-SQLite at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
>