Loading...
Request History
dstoecker created request
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
dimstar_suse set openSUSE:Factory:Staging:E as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:E"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:E"
dimstar accepted review
dimstar_suse accepted review
Staging Project openSUSE:Factory:Staging:E got accepted.
dimstar_suse approved review
Staging Project openSUSE:Factory:Staging:E got accepted.
dimstar_suse accepted request
Staging Project openSUSE:Factory:Staging:E got accepted.
This is a very bad change. The XS code tends to be heavily dependent on the exact SQLite version it ships with. We will have many problems because of this.
I agree. If upstream prefers bundling the dependency they might have reasons to do so and we shouldn't apply hacky patches leading to errors like https://progress.opensuse.org/issues/108272.
It's policy to use external libraries instead of bundled ones for SUSE. We do this unbundling in many packages. Issues result only in a very few of them.
Reason in upstream for bundling is mainly lazyness.
And the patch is not hacky, but already planned by the maintainers.
Manually changing the
if-statement looked like the entrance to the realm of unsupported configuration to me.That's the text above the "if":
Determine if we are going to use the provided SQLite code, or an already- installed copy. To this end, look for two command-line parameters:
USE_LOCAL_SQLITE -- If non-false, force use of the installed version
SQLITE_LOCATION -- If passed, look for headers and libs under this root
In absense of either of those, expect SQLite 3.X.X libs and headers in the common places known to Perl or the C compiler.
Note to Downstream Packagers: This block is if ( 0 ) to discourage casual users building against the system SQLite. We expect that anyone sophisticated enough to use a system sqlite is also sophisticated enough to have a patching system that can change the if ( 0 ) to if ( 1 )
We do have problems with the change, though: https://progress.opensuse.org/issues/108272
We have to check whether this is really a bug or maybe there is an "SQL logic error" which only was not detected in older versions.
I think this is a bug in Minion::Backend::SQLite. Look in the SQlite.pm
-- 1 down drop table if exists minion_jobs; drop table if exists minion_workers;
-- 2 up alter table minion_jobs add column attempts integer not null default 1;
-- 3 up create table minion_jobs_NEW ( id integer not null primary key autoincrement,
When I call this with sqlite3 manually it rejects this (position --2) as well, as the table does not exist, as it was dropped. That's perfectly logical. An "alter table" directly after a "drop table" is wrong.
Seems the the update of SQLite uncovers previously undetected errors.
The downs and the ups are independent of each other.
What do you mean? They are passed in one statement to the Sqlite.pm.
Sadly I found no way to get the real error message from perl+SQLite. Only via commandline tool. perl-SQlite interface does not pass through the reason why that statement fails.
They are not. It's a migration system that splits all the SQL statements and puts them in the right order for whatever migration is requested (maybe it only needs to migrate from version 2 to 3 and so on). I'm the upstream author of the migration system btw.
Ah. Right. Should have used the output of the debug text instead of going to the original source. Well. The debug output works without error when called in sqlite3 commandline.
It's also not the SQL from openQA that causes the issue. The actual migration that fails is from the upstream module
perl-Minion-Backend-SQLite.This would be the SQL statements in question: https://metacpan.org/dist/Minion-Backend-SQLite/source/lib/Minion/Backend/SQLite.pm#L1267
That causes the error. I wasn't yet able to strip it further. perl -I lib -e 'use Minion; use Minion::Backend::SQLite; my $minion = Minion->new('SQLite'); my $worker = $minion->repair;'
I was able to make Mojo::SQLite fail with this test: https://gist.github.com/perlpunk/db8b4f3cda9852fd9f32d3f352f5f9f9
It seems
check(json_valid(inbox) and json_type(inbox) = 'array')is the culpritsmaller reproducer: https://gist.github.com/perlpunk/7e96f3070a31c5f28a32a2d94ac4d634
Hmm, as far as I can see the local sqlite3.c contains the sqlite3 code as well as the local extensions. There is no useful way to get one without the other.
See https://build.opensuse.org/request/show/961703
I think in Minion-Backend-SQLite should be added a test for json capabilities. Suggested it here: https://github.com/Grinnz/Minion-Backend-SQLite/issues/20
Not providing the same features vanilla
DBD::SQLiteprovides is a packaging bug.After thinking a bit longer about todays tests: We should check WHY json stuff cannot be accessed. It should be available also in system sqlite3. Maybe it's only a linking issue? I could access it via sqlite3.c, so it should also go via perl.
Seems Debian has the same issue :-)
use DBD::SQLite;
my $dbh = DBI->connect("dbi:SQLite:dbname=a.db","","");
$dbh->do("create table if not exists minion_workers ( id integer not null primary key autoincrement, host text not null, pid integer not null, started text not null default current_timestamp, notified text not null default current_timestamp);");
$dbh->do("alter table minion_workers add column inbox text not null check(json_valid(inbox) and json_type(inbox) = 'array') default '[]'");
$dbh->do("insert into minion_workers values (1,'a',1,'2010-01-01','2010-01-01','[1]')");
$dbh->do("insert into minion_workers values (2,'a',1,'2010-01-01','2010-01-01','--')");
This works. Only fails through Mojo::SQLite?
https://github.com/Grinnz/Minion-Backend-SQLite/issues/20 contains test code where it works directly, but not using Mojo::SQLite. Anybody who finds the reason?
Ok. Enough for today. I could reduce it to "$dbh->sqlite_db_config(SQLITE_DBCONFIG_DQS_DML, 0);" (or using value 1013 directly).
Note from Debian: Seems the bug is gone with sqlite 3.38.1.