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 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@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:


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.

On Tue, 3 Nov 2009 11:03:09 +1100, Adam Kennedy 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 mailing list

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 17 | next ›
Discussion Overview
groupdbd-sqlite @
postedNov 3, '09 at 12:03a
activeNov 12, '09 at 11:59p



site design / logo © 2021 Grokbase