Control: found -1 1.011-1 Quoting David Cook (2017-07-07 08:39:28) > dcook@kohaprod:~/experiments/perlrdf/RDF-Trine/xt> git checkout > rdf-trine-1.011 > Note: checking out 'rdf-trine-1.011'. [...] > HEAD is now at cce3a8e5... Merge branch 'rdf-trine-1.011' into > release-rdf-trine > dcook@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.
Thanks for proving that that the bug exists also in RDF::Trine 1.011 (i.e. the version in Debian oldstable). Bugreport tagged accordingly. In other words, this bug is not a regression - users could not have depended on correct behaviour in the past and then have things failing merely by upgrading to a newer release of the Debian package. Which unfortunately makes for a weaker case of getting the fix applied to stable and oldstable Debian. :-/ > 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. Thanks for elaborating on use cases affected by this bug. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature