[
https://issues.apache.org/jira/browse/JENA-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17341847#comment-17341847
]
Rob Vesse commented on JENA-1963:
---------------------------------
My flippant answer is that I always knew making {{EXISTS}}/{{NOT EXISTS}} be
filter functions rather than graph patterns was a terrible idea.
I guess the fix here is to have that transform not consider {{FILTER}}
expressions that use those (unsafe) functions because of the different
execution semantics they imply
> Optimizer problem with NOT EXISTS and TransformFilterImplicitJoin
> -----------------------------------------------------------------
>
> Key: JENA-1963
> URL: https://issues.apache.org/jira/browse/JENA-1963
> Project: Apache Jena
> Issue Type: Bug
> Affects Versions: Jena 3.16.0
> Reporter: Andy Seaborne
> Priority: Major
> Attachments: D-exists.ttl, Q-exists.rq
>
>
> This is an example from the SPARQL 1.1 spec.
> It was reported to me directly and I refined it to isolate the problem to
> {{TransformFilterImplicitJoin}}.
> Run with normal optimziation, we get the wrong answer:
> {noformat}
> ~/tmp >> sparql --data D-exists.ttl --query Q-exists.rq
> ------------
> | x | n |
> ============
> | :b | 3.0 |
> | :a | 1 |
> ------------
> {noformat}
> With {{\--strict}}, or {{\--engine=ref}} or switching off just that one
> transform, we get the right answer.
> {noformat}
> ~/tmp >> sparql --set=arq:optFilterImplicitJoin=false --data D-exists.ttl
> --query Q-exists.rq
> ------------
> | x | n |
> ============
> | :b | 3.0 |
> ------------
> {noformat}
> Where {{D-exists.ttl}} is:
> {noformat}
> @prefix : <http://example.com/> .
> :a :p 1 .
> :a :q 1 .
> :a :q 2 .
> :b :p 3.0 .
> :b :q 4.0 .
> :b :q 5.0 .
> {noformat}
> and {{Q-exists.rq}} is:
> {noformat}
> PREFIX : <http://example.com/>
> SELECT * WHERE {
> ?x :p ?n
> FILTER NOT EXISTS {
> ?x :q ?m .
> FILTER(?n = ?m)
> }
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
