Sesame 2.8.4 subquery limit bug fix? - sparql

Question

It seems that there is bug in Sesame 2.8.4.
If I have the following data set:
#prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
#prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
#prefix : <http://example.org/>.
:a rdf:type :AClass .
:a :hasName "a"^^xsd:string .
:a :hasProperty :xa .
:a :hasProperty :ya .
:a :hasProperty :za .
:b rdf:type :AClass .
:b :hasName "b"^^xsd:string .
:b :hasProperty :xb .
:b :hasProperty :yb .
:c rdf:type :AClass .
:c :hasName "c"^^xsd:string .
:c :hasProperty :xc .
and run the following query on it:
prefix : <http://example.org/>
select ?s ?p ?o {
#-- first, select two instance of :AClass
{ select ?s { ?s a :AClass } limit 2 }
#-- then, select all the triples of
#-- which they are subjects
?s ?p ?o
}
The result I get back is this:
--------------------------------------------------------------------
| s | p | o |
====================================================================
| :a | <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> | :AClass |
| :a | :hasName | "a" |
--------------------------------------------------------------------
Instead of this one which is the correct result:
--------------------------------------------------------------------
| s | p | o |
====================================================================
| :a | <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> | :AClass |
| :a | :hasName | "a" |
| :a | :hasProperty | :xa |
| :a | :hasProperty | :ya |
| :a | :hasProperty | :za |
| :b | <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> | :AClass |
| :b | :hasName | "b" |
| :b | :hasProperty | :xb |
| :b | :hasProperty | :yb |
--------------------------------------------------------------------
Does anyone know about this bug? Has anybody encountered the same problem? Or is there another version of Sesame with this bug fixed?
The next line was added after my question was answered:
To avoid any confusions: The bug is in the Workbench and NOT the query engine.
The query engine works perfectly.

Answer 1

The problem you are seeing is not a bug in the query engine, but a bug in the Workbench client application (which also explains why I couldn't reproduce it earlier, as I was using the commandline client). For some reason Workbench incorrectly renders the result, showing only 2 rows (despite saying in the header that there are 9 results to be shown):
The problem is related to the result paging functionality in the Workbench, because when you change that setting it suddenly does show the complete result:
This issue has now been logged as a bug in Sesame's issue tracker: SES-2307.