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 dar...@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@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
___
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
