[
https://issues.apache.org/jira/browse/JENA-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17548265#comment-17548265
]
Claus Stadler edited comment on JENA-2332 at 6/4/22 2:18 PM:
-------------------------------------------------------------
It's good that the proper standard behavior is now clarified and adhered to.
And for the sake of robustness I'd also prefer if the queries in the systems we
are building now worked for the next few years without relying on unreported
bugs.
But this change breaks existing queries for me and probably others as well.
Currently with this fix I see no way to migrate those queries; so right now for
me it feels like that with this report I shot myself in the foot or locked
myself out with the keys still inside :)
What would be needed is some controlled way to get the "wrong" behavior.
Without any syntax extensions I was thinking about using SERVICE <correlate:>
(or SERVICE <linear:>) as a syntactic marker to force a linear join such that
e.g. JoinClassifier.isLinear returns true. I mean, Jena already has this
functionality - it's just not accessible from the outside because the SPARQL
spec does not yet provide a standard way for it.
Or maybe you have a better idea?
was (Author: aklakan):
It's good that the proper standard behavior is now clarified and adhered to.
And for the sake of robustness I'd also prefer if the queries in the systems we
are building now worked for the next few years without relying on unreported
bugs.
But this change breaks existing queries for me and probably others as well.
Currently with this fix I see no way to migrate those queries; so right now for
me it feels like that with this report I shot myself in the foot or locked
myself out with the keys still inside :)
What would be needed is some controlled way to get the "wrong" behavior.
Without any syntax extensions I was thinking about using SERVICE <correlate:>
(or SERVICE <linear:>) as a syntactic marker to force a linear join such that
e.g. JoinClassifier.isLinear returns true. I mean, Jena already has this
functionality - it's just not accessible from the outside because the SPARQL
spec does not provide a standard way for it.
Or maybe you have a better idea?
> Bad optimization transform when modifers used in SERVICE
> --------------------------------------------------------
>
> Key: JENA-2332
> URL: https://issues.apache.org/jira/browse/JENA-2332
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 4.5.0
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Major
> Fix For: Jena 4.6.0
>
>
> Report: https://lists.apache.org/thread/87wgds6c43j88829bscx4xkwsgcgq58p
> {noformat}
> SELECT * {
> SERVICE <https://dbpedia.org/sparql> { SELECT * { ?s a
> <http://dbpedia.org/ontology/MusicalArtist> } LIMIT 5 }
> SERVICE <https://dbpedia.org/sparql> { SELECT * { ?s
> <http://www.w3.org/2000/01/rdf-schema#label> ?x } LIMIT 1 }
> }
> {noformat}
> produces
> {noformat}
> (sequence
> (service <https://dbpedia.org/sparql>
> (slice _ 5
> (bgp (triple ?s <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
> <http://dbpedia.org/ontology/MusicalArtist>))))
> (service <https://dbpedia.org/sparql>
> (slice _ 1
> (bgp (triple ?s <http://www.w3.org/2000/01/rdf-schema#label> ?x)))))
> {noformat}
> but this query can't be transformed because of {{?s}}.
> It needs to remain as a join.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
