Norio Akagi created TINKERPOP-2911:
--------------------------------------
Summary: CountStrategy converts count().is(0) wrongly under
ConnectiveStrategy
Key: TINKERPOP-2911
URL: https://issues.apache.org/jira/browse/TINKERPOP-2911
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.5.5, 3.6.2, 3.4.13
Reporter: Norio Akagi
Fix For: 3.6.3
A query example:
// 2nd branch is just a dummy, and assuming we don't have an edge with label
"none"
g.V().where(or(out("none").out().count().is(0), has("none")))
Here, CountStrategy tries to convert {{count().is(0)}} to {{not(...).}}
However, when it is under ConnectiveStrategy, it tries to read Steps from tail
to beginning and include Steps until it finds the first non-filter Step. So in
this case, it becomes
[GraphStep(vertex,[]), OrStep([[VertexStep(OUT,[none],vertex),
NotStep([VertexStep(OUT,edge)])],
[TraversalFilterStep([NeptunePropertiesStep([none],property)])]])]
So the first out("none") is outside of NotStep, whereas the 2nd out() is inside.
The original intention of this query is that the 1st branch under {{or}} should
return {{true}} in the first branch, because there is no such edge with the
label {{"none"}} and {{{}count = 0{}}}.
However this optimization returns the opposite result. Because the first
{{VertexStep(OUT,[none],vertex)}} is now outside of {{{}NotStep{}}}, the 1st
branch returns {{{}false{}}}.
It seems this logic was intentionally introduced while back ago
[https://github.com/apache/tinkerpop/commit/36bd2a2447529371d950b2df6de36ea49957ab55]
So just reverting this change may not be the permanent fix. We should
investigate what should be the correct behavior for CountStrategy to apply
under ConnectivityStep.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
