It is indeed an interaction between Ima::DBI's use
of prepare_cached and SQLite's changed error.
Invalidating the $dbh->{CachedKids} is a passable
work-around. I tried and failed to globally
turn caching off in Ima::DBI::set_sql, but that
probably would have caused performance issues anyway.
I'm still not sure exactly which change revealed this
problem.
DBD::SQLite seems to be the correct place to address this
issue.
Does anyone else have an opinion on that matter?
Is there a better forum for
DBD::SQLite discussions? The only other seems to be RT.
$dbh->{CachedKids} = {}; # after ANALYZE or similar
# from the example
$dbh->prepare_cached('select "hello" from a');
print Dump $dbh->{CachedKids},"\n";
$dbh->{CachedKids} = {};
$dbh->do("analyze");
my $sth = $dbh->prepare_cached('select "hello" from a');
print "got ", $dbh->selectrow_array($sth), "\n";
A section of the DBI_TRACE from my main application
T <- prepare_cached('SELECT me.id
FROM step me
WHERE ( me.message = ? )
' undef ...)= DBIx::ContextualFetch::st=HASH(0x8e09f38) at DBI.pm line
+ 381
T <- FETCH('Active')= '' at DBI.pm line 1139
T <- FETCH('Taint')= 1 at ContextualFetch.pm line 50
<- STORE('Taint' 0)= 1 at ContextualFetch.pm line 51
!! ERROR: 1 'database schema has changed(1) at dbdimp.c line 421'
+(err#0)
<- execute('Removing duplicates')= undef at ContextualFetch.pm lin
+e 52
ERROR: 1 'database schema has changed(1) at dbdimp.c line 421'
+(err#0)
<> FETCH('Statement')= 'SELECT me.id
FROM step me
WHERE ( me.message = ? )
' ('Statement' from cache) at DBI.pm line 1143
Val::Step can't SELECT me.id
FROM step me
WHERE ( me.message = ? )
: DBD::SQLite::st execute failed: database schema has changed(1) at db
+dimp.c line 421 [for Statement "SELECT me.id
FROM step me
WHERE ( me.message = ? )
"] at /usr/share/perl5/DBIx/ContextualFetch.pm line 52.
at bin/validate.pl line 196
