[jira] [Comment Edited] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076371#comment-17076371
]
Jeremy Coulon edited comment on JENA-1877 at 4/6/20, 2:37 PM:
--
Thanks for the detailed explanations.
It is really hard to say how much our custom engine covers (about 60% of the
official test suite). Most op are only partially supported (even BGP). We have
a very pragmatic approach and don't support weird queries until one of our
client really needs high performance for such query. If performance are not
critical, we fallback to Jena in order to execute the query and give accurate
results. Thanks.
was (Author: jeremy.coulon):
Thanks for the detailed explanations.
It is really hard to say how much our custom engine covers. Most op are only
partially supported (even BGP). We have a very pragmatic approach and don't
support weird queries until one of our client really needs high performance for
such query. If performance are not critical, we fallback to Jena in order to
execute the query and give accurate results. Thanks.
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076371#comment-17076371
]
Jeremy Coulon commented on JENA-1877:
-
Thanks for the detailed explanations.
It is really hard to say how much our custom engine covers. Most op are only
partially supported (even BGP). We have a very pragmatic approach and don't
support weird queries until one of our client really needs high performance for
such query. If performance are not critical, we fallback to Jena in order to
execute the query and give accurate results. Thanks.
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076109#comment-17076109
]
Jeremy Coulon commented on JENA-1877:
-
I should say that this test was working fine with Jena 3.6. We just upgraded to
3.14 (big jump).
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076107#comment-17076107
]
Jeremy Coulon commented on JENA-1877:
-
That's not how I read the spec:
{noformat}
If the form with a simple literal is used, every call results in distinct blank
nodes for different simple literals, and the same blank node for calls with the
same simple literal within expressions for one solution mapping.{noformat}
Note about how I discoved this:
I am using Jena in order to parse sparql query and create an algebra with it.
Then I am transforming part of this algebra into my own custom op (much is more
than just BGP). Default Jena optimizations can sometimes be
counter-optimizations in my case. Thus most optimizations are disabled. I then
run the sparql test suite in order to check for regressions:
[https://www.w3.org/2009/sparql/docs/tests/summary.html#functions-bnode01]
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074651#comment-17074651
]
Jeremy Coulon edited comment on JENA-1877 at 4/3/20, 3:19 PM:
--
I am not sure that I was perfectly clear.
The real symptoms in my case is that non-optimized query returns (wrong!):
{noformat}
---
| s1| s2| b1 | b2 |
===
| "BAZ" | "BAZ" | _:b0 | _:b1 |
| "BAZ" | "foo" | _:b2 | _:b3 |
| "foo" | "BAZ" | _:b4 | _:b5 |
| "foo" | "foo" | _:b6 | _:b7 |
---{noformat}
while optimized query returns (correct!):
{noformat}
---
| s1| s2| b1 | b2 |
===
| "foo" | "BAZ" | _:b0 | _:b1 |
| "foo" | "foo" | _:b2 | _:b2 |
| "BAZ" | "BAZ" | _:b3 | _:b3 |
| "BAZ" | "foo" | _:b4 | _:b5 |
---{noformat}
was (Author: jeremy.coulon):
I am not sure that I was perfectly clear.
The real symptoms in my case is that non-optimized query returns:
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JENA-1877) Wrong results for non-optimized query
[
https://issues.apache.org/jira/browse/JENA-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074651#comment-17074651
]
Jeremy Coulon commented on JENA-1877:
-
I am not sure that I was perfectly clear.
The real symptoms in my case is that non-optimized query returns:
> Wrong results for non-optimized query
> -
>
> Key: JENA-1877
> URL: https://issues.apache.org/jira/browse/JENA-1877
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
>Affects Versions: Jena 3.14.0
>Reporter: Jeremy Coulon
>Priority: Major
> Attachments: bnode01.rq, data.ttl
>
>
> I noticed that the attached query gives correct results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
> {noformat}
> while it gives wrong results with:
> {noformat}
> ./bin/arq --data=data.ttl --query=bnode01.rq --explain
> --optimize=off{noformat}
> Without optimization, ARQ algebra has 2 different 'extend' op with
> 'bnode(?s)' expression.
> With optimization, ARQ algebra merges these ops into a single op 'extend'.
>
> I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
> 'binding' object for each call in optimized mode but different 'binding'
> objects for non-optimized mode. This function relies on reference-equality.
>
> [^data.ttl]
> [^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JENA-1877) Wrong results for non-optimized query
Jeremy Coulon created JENA-1877:
---
Summary: Wrong results for non-optimized query
Key: JENA-1877
URL: https://issues.apache.org/jira/browse/JENA-1877
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 3.14.0
Reporter: Jeremy Coulon
Attachments: bnode01.rq, data.ttl
I noticed that the attached query gives correct results with:
{noformat}
./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=on
{noformat}
while it gives wrong results with:
{noformat}
./bin/arq --data=data.ttl --query=bnode01.rq --explain --optimize=off{noformat}
Without optimization, ARQ algebra has 2 different 'extend' op with 'bnode(?s)'
expression.
With optimization, ARQ algebra merges these ops into a single op 'extend'.
I tried debugging and I think that 'E_BNode.evalSpecial()' takes the same
'binding' object for each call in optimized mode but different 'binding'
objects for non-optimized mode. This function relies on reference-equality.
[^data.ttl]
[^bnode01.rq]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JENA-1519) OpWalkerVisitor should interact better with custom operators
Jeremy Coulon created JENA-1519:
---
Summary: OpWalkerVisitor should interact better with custom
operators
Key: JENA-1519
URL: https://issues.apache.org/jira/browse/JENA-1519
Project: Apache Jena
Issue Type: Bug
Components: ARQ
Affects Versions: Jena 3.6.0
Reporter: Jeremy Coulon
When visiting an OpExt, current implementation of OpWalkerVisitor is just
calling the visitor on opExt.effectiveOp().
However if OpExt is replacing a sub-tree of the algebra instead of a single
leaf node, the sub-tree is ignored by walker.
I found this bug when trying to execute a query with a MINUS operator with
either side of the operator being replaced by an custom operator.
For example the following query is not working, if I transform both side of
MINUS with a custom operator:
{{(project (?animal)}}
{{ (minus}}
{{ (bgp (triple ?animal rdf:type ex:Animal))}}
{{ (filter (|| (= ?type ex:Reptile) (= ?type ex:Insect))}}
{{ (bgp (triple ?animal rdf:type ?type)}}
which I transform into:
{{(project (?animal)}}
{{ (minus}}
{{ (op-ext )}}
{{ (op-ext )))}}
The reason is that MINUS is calling OpVars.visibleVars() which does not walk
into the subop of the filter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JENA-1517) Some queries not working when using OpQuadBlock
Jeremy Coulon created JENA-1517: --- Summary: Some queries not working when using OpQuadBlock Key: JENA-1517 URL: https://issues.apache.org/jira/browse/JENA-1517 Project: Apache Jena Issue Type: Bug Components: ARQ Affects Versions: Jena 3.6.0 Reporter: Jeremy Coulon I am using a custom QueryEngine that rewrites algebra. I am transforming OpBGP into OpQuadBlock (not OpQuadPattern). Most queries work fine except when using one of the following: * MINUS * FILTER EXISTS * FILTER NOT EXISTS I tracked the issue down to this visitor: org.apache.jena.sparql.algebra.OpVarsPattern. An override for visit(OpQuadBlock) is missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
