[
https://issues.apache.org/jira/browse/JENA-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15308166#comment-15308166
]
Andy Seaborne edited comment on JENA-1187 at 5/31/16 8:58 PM:
--------------------------------------------------------------
This is due to a bug fix, JENA-1018 at Jena 3.0.1. The JIRA describes ways to
test this (turn the optimizer off with {{--opt=off}} on the command line).
Reduced example:
{noformat}
SELECT * {
BIND("nonexistant" AS ?cl)
{
BIND(?cl AS ?cl2)
?c a ?cl2 .
}
}
{noformat}
SPARQL evaluates inner expressions then combines them together. So what is
happens is that inner {{BIND(?cl AS ?cl2)}} has {{?cl}} unbound, so {{?cl2}} is
unbound and {{?c a ?cl2}} matches. Then the outer {{BIND("nonexistant" AS
?cl)}} comes into play - it is joined with the results from the inner
expression, which has no {{?cl}} so just adds a column.
If {{?c a ?cl2}} becomes {{?c a ?cl}} then ?cl matches due to the pattern only
and is joined with the outer {{?cl}} which never matches.
It is useful to put a marker into UNION branches to debug:
{noformat}
{
BIND (1 AS ?unionBranch)
...
} UNION {
BIND (2 AS ?unionBranch)
...
}
{noformat}
was (Author: andy.seaborne):
This is due to a bug fix, JENA-1018 at Jena 3.0.1. The JIRA describes ways to
test this (turn the optimizer off with {{--opt=off}} on the command line).
Reduced example:
{noformat}
SELECT * {
BIND("nonexistant" AS ?cl)
{
BIND(?cl AS ?cl2)
?c a ?cl2 .
}
}
{noformat}
SPARQL evaluates inner expressions then combines them together. So what is
happens is that inner {{BIND(?cl AS ?cl2)}} has {{?cl}} unbound, so {{?cl2}} is
unbound and {{?c a ?cl2}} matches. Then the outer {{BIND("nonexistant" AS
?cl)}} comes into play - it is joined with the results from the inner
expression, which has no {{?cl}} so just adds a column.
> Wrong results/performance regression when using BIND and graph pattern groups
> -----------------------------------------------------------------------------
>
> Key: JENA-1187
> URL: https://issues.apache.org/jira/browse/JENA-1187
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Affects Versions: Jena 3.1.0, Fuseki 2.4.0
> Reporter: Eetu Mäkelä
>
> I've been using SPARQL queries with BINDs and/or VALUESs that precede UNION
> blocks. These used to work efficiently (at least in Jena 2 times) with the
> bound value being bound also in the subpattern, but no longer do. In
> addition, at certain times, they produce nonsensical results. For example,
> the below returns {{rdf:type}} statements in the dataset without any regard
> to ?cl:
> {code}
> SELECT * {
> {
> BIND("nonexistant" AS ?cl)
> {
> BIND(?cl AS ?cl2)
> ?c a ?cl2 .
> } UNION {
> BIND(?cl AS ?cl2)
> ?c a ?cl2 .
> }
> }
> }
> LIMIT 10
> {code}
> while if you change _just one_ of the subpatterns in the union to directly
> refer to ?cl, it returns an empty result set:
> {code}
> SELECT * {
> {
> BIND("nonexistant" AS ?cl)
> {
> BIND(?cl AS ?cl2)
> ?c a ?cl .
> } UNION {
> BIND(?cl AS ?cl2)
> ?c a ?cl2 .
> }
> }
> }
> LIMIT 10
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
