[ https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072994#comment-17072994 ]
Andy Seaborne commented on JENA-1877: ------------------------------------- Hi - thanks for the report with details and analysis. I think the non-optimized is right-by-the-spec. Section 18.2.4.4 "SELECT Expressions" nests one "extend" for each expression in the SELECT clause. SPARQL itself does not have an n-ary (extend). The built-in no-frills execution engine agrees with the not-optimized version. It can be accessed with command line {{--engine=ref}}; it does not scale or have great performance. It is possible to control the individual optimizer steps. {{--set arq:optMergeExtends=false}} will switch off the transformation that is involved. > Wrong results for non-optimized query > ------------------------------------- > > Key: JENA-1877 > URL: https://issues.apache.org/jira/browse/JENA-1877 > Project: Apache Jena > Issue Type: Bug > Components: ARQ > Affects Versions: Jena 3.14.0 > Reporter: Jeremy Coulon > Priority: Major > Attachments: bnode01.rq, data.ttl > > > I noticed that the attached query gives correct results with: > {noformat} > ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on > {noformat} > while it gives wrong results with: > {noformat} > ./bin/arq --data=data.ttl --query=bnode01.rq --explain > --optimize=off{noformat} > Without optimization, ARQ algebra has 2 different 'extend' op with > 'bnode(?s)' expression. > With optimization, ARQ algebra merges these ops into a single op 'extend'. > > I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same > 'binding' object for each call in optimized mode but different 'binding' > objects for non-optimized mode. This function relies on reference-equality. > > [^data.ttl] > [^bnode01.rq] -- This message was sent by Atlassian Jira (v8.3.4#803005)