I don't see much reason to honor $ENV{DBI_DSN} at all. Case 2 would at leave others the possibility to change which database tests are run against, but as at least some of the tests are destructive, I consider the potential risk to be far higher than the potential gains in running the SQLite tests. So unless somebody comes up with a convincing argument when $ENV{DBI_DSN} can be of help during testing a (potentially unstable or disastrous) new version of DBD::SQLite, it'll go out. Personally, I'm even in favor of trying :memory: databases instead of using temporary files, because a memory database leaves nothing behind if the test crashes.
Update: In fact, after looking at the code, that part has already been removed, even though the blamelog doesn't tell me exactly where.
In reply to Re^2: Working on a new DBD::SQLite release
by Corion
in thread Working on a new DBD::SQLite release
by Corion
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |