OK. Agreed. Kenichi
On Tue, 03 Nov 2009 21:28:59 -0800, Darren Duncan <dar...@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 > >_______________________________________________ >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