You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@jena.apache.org by "Claus Stadler (Jira)" <ji...@apache.org> on 2022/06/04 14:16:00 UTC
[jira] [Comment Edited] (JENA-2332) Bad optimization transform when modifers used in SERVICE
[ 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:15 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.
Or maybe you have a better idea?
was (Author: aklakan):
It's good that the proper standard behavior is now clarified and adhered to. 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.
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: jira-unsubscribe@jena.apache.org
For additional commands, e-mail: jira-help@jena.apache.org