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
