[
https://issues.apache.org/jira/browse/JENA-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13613087#comment-13613087
]
Rob Vesse commented on JENA-422:
--------------------------------
I have my fix and a number of new unit tests in place for OpAsQuery.
The fix both resolves the underlying cause which is that a top level BIND would
not round trip and fixes the specific reported issue that BIND inside a SERVICE
clause would not be propagated to the remote service.
> SERVICE execution does not propogate BINDs within the SERVICE clause
> --------------------------------------------------------------------
>
> Key: JENA-422
> URL: https://issues.apache.org/jira/browse/JENA-422
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 2.10.0
> Reporter: Rob Vesse
> Assignee: Rob Vesse
> Labels: federation, service, sparql
> Fix For: Jena 2.10.1
>
>
> This was originally spotted thanks to a user question at
> http://answers.semanticweb.com/questions/21759/using-bind-and-service-in-fuseki
> The basic problem described there is that a BIND used within a SERVICE clause
> appeared to have no effect.
> I was able to reproduce this with a minimal Fuseki setup using an in-memory
> dataset containing a single triple and the following query:
> SELECT * WHERE { SERVICE <http://localhost:3030/ds/query> { ?s ?p ?o .
> BIND(?o AS ?x) } }
> I have a unit test for Fuseki that demonstrates the behaviour as well. Under
> the debugger I can see that the BIND clause is not included in the query
> string that gets sent to the remote service hence the lack of values for the
> BINDed variable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
