Bug#865506: Upgrade buggy librdf-trine-perl with new release in Debian Jessie

[David Cook]

Hi Dominic,

Thanks for your email, and apologies for the delay in my response. 

Thanks for merging the bugs together. I wasn't sure of the protocol due to
the structure of the template required for reporting. 

So I'm the reporter from https://github.com/kasei/perlrdf/issues/146. In my
patch
(https://github.com/minusdavid/perlrdf/commit/fbe2d3f8679cc134a38bd848d60b43
ba9e1720e2), I include a unit test to check for the problem in the report. 

If you clone that repo and go to the master branch and copy
"perlrdf/RDF-Trine/xt/store-sparql.t" to
perlrdf/RDF-Trine/xt/store-sparql2.t, checkout an earlier verison, and then
perl using the RDF::Trine modules from the Git repo, you should see the
buggy behaviour. I'll do it myself and paste the results below:

dcook at kohaprod:~/experiments/perlrdf/RDF-Trine/xt> git checkout
rdf-trine-1.011
Note: checking out 'rdf-trine-1.011'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at cce3a8e5... Merge branch 'rdf-trine-1.011' into
release-rdf-trine
dcook at kohaprod:~/experiments/perlrdf/RDF-Trine/xt> perl -I
~/experiments/perlrdf/RDF-Trine/lib store-sparql2.t
1..17
ok 1 - add_statement throws error with no statement
ok 2 - remove_statement throws error with no statement
ok 3 - There should just be one _add_statements aggregated operation
ok 4 - Type is correct: _add_statements
not ok 5 - There should be two ops here
#   Failed test 'There should be two ops here'
#   at store-sparql2.t line 37.
#          got: '3'
#     expected: '2'
not ok 6 - There should be two statements being posted.
#   Failed test 'There should be two statements being posted.'
#   at store-sparql2.t line 52.
#          got: '1'
#     expected: '2'
ok 7 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 8 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 9 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 10 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 11 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 12 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 13 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 14 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 15 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 16 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
ok 17 # skip No network. Set RDFTRINE_NETWORK_TESTS to run these tests.
# Looks like you failed 2 tests of 17.

Basically, the scenario is that RDF::Trine::Model->begin_bulk_ops() doesn't
work with RDF::Trine::Store::SPARQL, because
RDF::Trine::Store::SPARQL::_group_bulk_ops() doesn't create the data
structure correctly. So instead of storing 2 operations in an array, it
creates an array containing 1 op and junk data. When it comes time to post
to the SPARQL HTTP endpoint, only the 1 op gets posted and the rest of the
junk data is just silently ignored. 

If you have a functional SPARQL endpoint, you can test this by creating a
RDF::Trine::Store::SPARQL object for that endpoint, a RDF::Trine::Model with
that store object, creating RDF::Trine::Statements, running
RDF::Trine::Model->begin_bulk_ops(), adding the RDF::Trine::Statements via
RDF::Trine::Model->add_statement(), and then running
RDF::Trine::Model->end_bulk_ops(), and you'll only ever get 1 triple
correctly inserted. The other N triples will be ignored. RDF::Trine::Model
returns nothing meaningful, so you'd have to send an additional SPARQL query
to the RDF triplestore in order to verify that anything has been
inserted/not inserted.

Please let me know if you need any more information, and I'll do my best to
reply more promptly next time.

David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Australia

Office: 02 9212 0899
Direct: 02 8005 0595


-----Original Message-----
From: Dominic Hargreaves [mailto:dom at earth.li] 
Sent: Thursday, 22 June 2017 7:24 PM
To: David Cook <dcook at prosentient.com.au>; 865506 at bugs.debian.org
Subject: Re: Bug#865506: Upgrade buggy librdf-trine-perl with new release in
Debian Jessie

Control: tags -1 + moreinfo

On Thu, Jun 22, 2017 at 03:47:15PM +1000, David Cook wrote:
> Versions of RDF::Trine prior to 1.017 have buggy implementations of 
> bulk_ops methods in RDF::Trine::Store::SPARQL, which causes only 1 RDF 
> triple to be inserted into a triplestore when you are trying to insert 
> more than 1 triple in bulk.
> 
>  
> 
> This was fixed in version 1.017 with the commit
> https://github.com/kasei/perlrdf/commit/fbe2d3f8679cc134a38bd848d60b43
> ba9e17
> 20e2. 
> 
>  
> 
> Jonas Smedegaard has already uploaded the most recent version of 
> RDF::Trine to Debian Sid 
> (https://packages.debian.org/sid/librdf-trine-perl), and I'm hoping that
this package can be backported to Debian Jessie.

Hi,

There's no need to file duplicate bug reports for different releases - the
information on affected releases is stored within the bug, so I've merged
the two together.

In https://github.com/kasei/perlrdf/issues/146 I note that the reporter only
mentions RDF::Trine 1.016 and nothing earlier. Do you have a test case that
we can use to verify whether this is broken on earlier releases?

Best,
Dominic.