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

Kenichi Ishigaki kishigaki at gmail.com
Wed Nov 4 05:04:31 GMT 2009

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.


On Wed, 4 Nov 2009 14:28:12 +1100, Adam Kennedy <adamkennedybackup at gmail.com> wrote:

>The fact support is still light is all the more reason to get optional
>support out there in wide distribution, so more than just this mailing
>list have a chance to test it thoroughly.
>At the moment, we're holding up this testing to just the people
>willing to play with potentially unstable releases.
>As for why have a prod release, because of all the other fixes and
>changes we've got bundled up. We finally pass our test suite
>completely everywhere, so far as I can tell from CPAN Testers. I
>really want that out there.
>Adam K
>2009/11/3 Kenichi Ishigaki <kishigaki at gmail.com>:
>> Then let's wait for another month and another sqlite release.
>> Releasing just before this Christmas would make more sense.
>> In the end, the current sqlite is the first version with
>> foreign keys support. They are doing pubic tests right now,
>> and we haven't seen, and will see the result probably in a
>> month or so. Why do we need to rush out our stable release?
>> As I wrote in the previous mail, we need more tests. As of
>> this writing, we have virtually no tests for foreign keys
>> and virtual tables they use.
>> Besides, we have #48600 that reported several downstream
>> distributions were revealed broken by our more strict
>> error handling, which I haven't checked fully but it looks
>> like they still have issues like this:
>> http://rt.cpan.org/Public/Bug/Display.html?id=50591
>> Probably we should let people know that sqlite has been
>> supporting "IF (NOT) EXISTS" for some (or a long?) time,
>> and they can fix these issue with that clause right now,
>> even before our next stable release. A few nights ago,
>> DBIC people also found this issue, and they said maybe
>> their issue can be fixed in DBIC. It's better to give
>> people more time to test.
>> I think removing the on-by-default bit doesn't help,
>> especially if it's to release early. It will eventually
>> be turned on. And most probably they know how to cope with
>> it when it's enabled. As foreign keys have long been ignored,
>> if they are already there, they are for other engines people
>> are using in other places.
>> Kenichi
>> On Tue, 3 Nov 2009 11:03:09 +1100, Adam Kennedy <adamkennedybackup at gmail.com> 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.
>>>Adam K
>>>DBD-SQLite mailing list
>>>DBD-SQLite at lists.scsys.co.uk
>> _______________________________________________
>> DBD-SQLite mailing list
>> DBD-SQLite at lists.scsys.co.uk
>> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite

More information about the DBD-SQLite mailing list