Skip Menu |

This queue is for tickets about the DBD-SQLite CPAN distribution.

Report information
The Basics
Id: 124227
Status: resolved
Priority: 0/
Queue: DBD-SQLite

People
Owner: Nobody in particular
Requestors: ribasushi [...] leporine.io
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 1.55_05
Fixed in: (no value)



Subject: SQL-level regression ( likely libsqlite )
Using latest DBI, the attached script gives different results depending on which DBD::SQLite trial I am using. This breaks a ( much more convoluted ) DBIC test. This is *NOT* related to previous DBIC-reported breakages, this one is brand new. 3.17.0 ( DBD::SQLite@1.55_03 ) results as expected $VAR1 = { '1.55_03' => [ [ 4 ], [ 5 ] ] }; 3.21.0 ( DBD::SQLite@1.55_04 ) gets one more result than I would expect $VAR1 = { '1.55_04' => [ [ 1 ], [ 4 ], [ 5 ] ] };
Subject: sqlite_indexing_convoluted.txt
use warnings; use strict; use DBI; use Data::Dumper; my $dbh = DBI->connect( 'dbi:SQLite::memory:', undef, undef, { RaiseError => 1 } ); $dbh->do($_) for ( 'CREATE TABLE cd ( cdid INTEGER PRIMARY KEY NOT NULL, genreid integer )', 'CREATE INDEX cd_idx_genreid ON cd (genreid)', 'INSERT INTO cd ( cdid, genreid ) VALUES ( 1, 1 ), ( 2, NULL ), ( 3, NULL ), ( 4, NULL ), ( 5, NULL ) ', ); warn Dumper { DBD::SQLite->VERSION => $dbh->selectall_arrayref(<<'EOS') }; SELECT cdid FROM cd me WHERE 2 > ( SELECT COUNT( * ) FROM cd rownum__emulation WHERE ( me.genreid IS NOT NULL AND rownum__emulation.genreid IS NULL ) OR ( me.genreid IS NOT NULL AND rownum__emulation.genreid IS NOT NULL AND rownum__emulation.genreid < me.genreid ) OR ( ( me.genreid = rownum__emulation.genreid OR ( me.genreid IS NULL AND rownum__emulation.genreid IS NULL ) ) AND rownum__emulation.cdid > me.cdid ) ) EOS
On Sat Jan 27 05:19:30 2018, RIBASUSHI wrote: Show quoted text
> Using latest DBI, the attached script gives different results > depending on which DBD::SQLite trial I am using. This breaks a ( much > more convoluted ) DBIC test. > > This is *NOT* related to previous DBIC-reported breakages, this one is > brand new. > > 3.17.0 ( DBD::SQLite@1.55_03 ) results as expected > $VAR1 = { > '1.55_03' => [ > [ > 4 > ], > [ > 5 > ] > ] > }; > > > 3.21.0 ( DBD::SQLite@1.55_04 ) gets one more result than I would > expect > $VAR1 = { > '1.55_04' => [ > [ > 1 > ], > [ > 4 > ], > [ > 5 > ] > ] > };
Thanks. Reported to the upstream. Interestingly this can be fixed by disabling SQLITE_ENABLE_STAT[34] compile time options (with 3.20.0 and onward; 3.19.3 and prior pass this test without any modification), but it doesn't seem to be enough to make DBIC's t/prefetch/grouped.t pass. I'm not sure yet if this is oversimplified, or there's something more to the test. For now I shipped two developer releases to test.
Latest trial of DBIC [1] properly works under both DBD::SQLite trial versions. I have temporarily disabled the problematic test so that a smoker with a stale DBD::SQLite won't give me false positives ( the test itself is non-essential ): https://github.com/Perl5/DBIx-Class/commit/a05b82dcf9f I am expecting [1] to become a non-dev release some time early next week. Thank you *SO MUCH* for your patience ;) [1] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.082840_01
On Sun Jan 28 23:30:51 2018, RIBASUSHI wrote: Show quoted text
> Latest trial of DBIC [1] properly works under both DBD::SQLite trial > versions. I have temporarily disabled the problematic test so that a > smoker with a stale DBD::SQLite won't give me false positives ( the > test itself is non-essential ): https://github.com/Perl5/DBIx- > Class/commit/a05b82dcf9f > > I am expecting [1] to become a non-dev release some time early next > week. Thank you *SO MUCH* for your patience ;) > > [1] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.082840_01
Thank YOU for your hard work! I'll start the normal release procedure by posting a blog entry to explain notable changes after DBIC goes stable. I hope I can release 1.56 stable at the end of Feb, or just before the coming YAPC::Okinawa, though this may slightly change if a new patched libsqlite comes in time.
On Mon Jan 29 04:22:23 2018, ISHIGAKI wrote: Show quoted text
> I'll start the normal release procedure by posting a blog entry to > explain notable changes after DBIC goes stable.
It just did, please proceed. Show quoted text
> I hope I can release > 1.56 stable at the end of Feb, or just before the coming > YAPC::Okinawa, though this may slightly change if a new patched > libsqlite comes in time.
Given the type of bug and how long it went undetected, I personally would go with 3.19.3, and let 3.20+ be tripple checked by rhipp behind the scenes ( as I am sure he already is ;) But this is just a suggestion of course, your call ;)
On Mon Jan 29 18:36:13 2018, RIBASUSHI wrote: Show quoted text
> On Mon Jan 29 04:22:23 2018, ISHIGAKI wrote: >
> > I'll start the normal release procedure by posting a blog entry to > > explain notable changes after DBIC goes stable.
> > > It just did, please proceed.
Done. http://blogs.perl.org/users/kenichi_ishigaki/2018/01/next-stable-dbdsqlite-will-be-released-at-the-end-of-february.html Show quoted text
>
> > I hope I can release > > 1.56 stable at the end of Feb, or just before the coming > > YAPC::Okinawa, though this may slightly change if a new patched > > libsqlite comes in time.
> > > Given the type of bug and how long it went undetected, I personally > would go with 3.19.3, and let 3.20+ be tripple checked by rhipp behind > the scenes ( as I am sure he already is ;) > > But this is just a suggestion of course, your call ;)
Considering the number of bugfixes since 3.20.0+, I'd rather go with 3.22.0. Actually I really wondered which version should I take this time, because each version seemed to have fixed a long standing bug or two ;) It's probably more important for me to release dev versions more often, maybe each time new libsqlite is released, so that we can find our issues earlier.
Marked as resolved. Thanks.