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