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. Kenichi On Wed, 4 Nov 2009 14:28:12 +1100, Adam Kennedy <adamkennedybac...@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 <kishig...@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 >> <adamkennedybac...@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. >>> >>>Thoughts? >>> >>>Adam K >>> >>>_______________________________________________ >>>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 >> _______________________________________________ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite