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

[Darren Duncan]

It seems that Christmas came early this month.  SQLite 3.6.20 was released 2 
hours ago, and I committed it into the repository.  And so the "last dev 
release" 1.26_07 can include that, and prod can have it 3-4 days later as you 
say. -- Darren Duncan

Adam Kennedy wrote:
> Righto, so I'm going to roll an official "release candidate" dev
> version now, and we code freeze at this point (just docs and test
> tweaks allowed between now and final).
> 
> I'll let the last dev release cook for 3 or 4 days, then do the prod one.
> 
> Adam K
> 
> 2009/11/4 Kenichi Ishigaki <kishigaki at gmail.com>:
>> OK. Agreed.
>>
>> Kenichi
>>
>> On Tue, 03 Nov 2009 21:28:59 -0800, Darren Duncan <darren at darrenduncan.net> wrote:
>>
>>> Kenichi Ishigaki wrote:
>>>> Our tests are hardly thorough and complete, and while I tried
>>>> to write a test for foreign keys, I was hit by a weird bug
>>>> that suggested the internal sqlite3 object and the DBI/DBD::SQLite
>>>> handle objects were holding different statuses; the same statement
>>>> works fine when issued one by one with do, and fails with consecutive
>>>> executes. This may not be a showstopper, but is certainly annoying.
>>>> (I haven't added the test yet, thoguh. I don't want it to be disabled
>>>> again like the one I added just before 1.26_05).
>>>>
>>>> Anyway, I agree to comment out the pragma to turn off the default
>>>> foreign keys support tentatively. But I do insist we should wait
>>>> at least for two weeks, until the sqlite team release the next
>>>> monthly update.
>>> If you mean we should wait 2 weeks and then issue the 1.27-stable as soon as
>>> SQLite 3.6.20 comes out and include that, for the main reason that this would
>>> include the first batch of fixes (if any) to SQLite itself following its
>>> foreign-keys major update, then that sounds reasonable, so our testers of
>>> foreign keys get those fixes.  Especially relevant if the changes to add foreign
>>> key enforcement might have broken something unrelated to foreign keys.  But we
>>> should wait no longer than 3.6.20 to issue our own stable release.  And our
>>> stable would have foreign keys disabled by default. -- Darren Duncan