[
https://issues.apache.org/jira/browse/TINKERPOP-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751200#comment-17751200
]
Stephen Mallette commented on TINKERPOP-2961:
---------------------------------------------
coming back to this after a long while - sorry it took so long.
> The two queries are equivalent, the only difference is the expression of the
> traversal "__.as("n4").both().out().out().out().out().as("n2")".
if you reversed the bindings i think it's expected that there would be a
difference in the result. take a more simplistic example:
{code}
gremlin> g.V().match(__.as('a').out('created').as('b'),
......1> __.as('b').has('name', 'lop'),
......2> __.as('b').in('created').as('c'),
......3> __.as('c').has('age', 29)).
......4> select('a','c').by('name')
==>[a:marko,c:marko]
==>[a:josh,c:marko]
==>[a:peter,c:marko]
gremlin> g.V().match(__.as('a').out('created').as('b'),
......1> __.as('b').has('name', 'lop'),
......2> __.as('c').out('created').as('b'),
......3> __.as('c').has('age', 29)).
......4> select('a','c').by('name')
The provided match pattern is unsolvable: [[MatchStartStep(c),
VertexStep(OUT,[created],vertex), MatchEndStep(b)], [MatchStartStep(c),
HasStep([age.eq(29)]), MatchEndStep(null)], [MatchStartStep(b),
HasStep([name.eq(lop)]), MatchEndStep(null)], [MatchStartStep(a),
VertexStep(OUT,[created],vertex), MatchEndStep(b)]]
Type ':help' or ':h' for help.
Display stack trace? [yN]
{code}
reversing things in line 2 is unsolvable in this case. in the first example "b"
is a "software" vertex bound from that first line so it works nicely when you
traverse {{in('created')}}. But when you reversed it, "c" is not yet bound to
anything and is thus unsolvable.
Please re-read the {{match()}} documentation
[here](https://tinkerpop.apache.org/docs/current/reference/#match-step) as
there is a neat paragraph there that explains this. I will post here for
convenience:
{quote}
There are three types of match() traversal patterns.
1. as('a')…as('b'): both the start and end of the traversal have a declared
variable.
2. as('a')…: only the start of the traversal has a declared variable.
3. …: there are no declared variables.
If a variable is at the start of a traversal pattern it must exist as a label
in the path history of the traverser else the traverser can not go down that
path. If a variable is at the end of a traversal pattern then if the variable
exists in the path history of the traverser, the traverser’s current location
must match (i.e. equal) its historic location at that same label. However, if
the variable does not exist in the path history of the traverser, then the
current location is labeled as the variable and thus, becomes a bound variable
for subsequent traversal patterns. If a traversal pattern does not have an end
label, then the traverser must simply "survive" the pattern (i.e. not be
filtered) to continue to the next pattern. If a traversal pattern does not have
a start label, then the traverser can go down that path at any point, but will
only go down that pattern once as a traversal pattern is executed once and only
once for the history of the traverser. Typically, traversal patterns that do
not have a start and end label are used in conjunction with and(), or(), and
where(). Once the traverser has "survived" all the patterns (or at least one
for or()), match()-step analyzes the traverser
{quote}
The first sentence of the big paragraph describes this important condition that
is being violated. The exception for "a" in this case is also noted as you read
further along.
> Missing exceptions for unsolvable match pattern, which may lead to logic
> inconsistency
> --------------------------------------------------------------------------------------
>
> Key: TINKERPOP-2961
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2961
> Project: TinkerPop
> Issue Type: Bug
> Components: process
> Affects Versions: 3.6.0
> Reporter: Miracy Cavendish
> Priority: Major
> Attachments: create-8.log
>
>
> Hi all! From
> [Discord|https://discord.com/channels/838910279550238720/1064868348925583442/threads/1117146194666332250].
> We noticed that in some cases unsolvable matching will not lead to the
> exception "unsolvable pattern" in Gremlin.
> For a simple example, in the empty graph, the following query will not lead
> to an exception, while it will result in an exception in the GraphModern:
> {code:java}
> g.V().match(__.as("A").out().as("B"), __.as("C").out().as("B"),
> __.as("D").out().as("A"))
> {code}
> In more complex cases, this missing may lead to a worse result.
> For example, in the graph created by attachment _create-8.log_
> {code:java}
> g.V().match(
> __.as("n2").out().as("n1"),
> __.as("n2").in().in().in().both().in().as("n1"),
> __.as("n2").both().in().in().as("n3"),
> __.as("n3").in().both().as("n2"),
> __.as("n2").in().in().in().in().both().as("n4"),
> __.as("n2").out().both().in().as("n4"),
> __.as("n3").both().as("n4"),
> __.as("n1").in().both().both().both().as("n5")
> ).dedup().count()
> =>306691
> g.V().match(
> __.as("n2").out().as("n1"),
> __.as("n2").in().in().in().both().in().as("n1"),
> __.as("n2").both().in().in().as("n3"),
> __.as("n3").in().both().as("n2"),
> __.as("n4").both().out().out().out().out().as("n2"),
> __.as("n2").out().both().in().as("n4"),
> __.as("n3").both().as("n4"),
> __.as("n1").in().both().both().both().as("n5")
> ).dedup().count()
> =>306075
> {code}
> The two queries are equivalent, the only difference is the expression of the
> traversal "__.as("n4").both().out().out().out().out().as("n2")".
> I am not sure which of their results in the correct result, but the logic
> inconsistency indicates that the missing exception may cause worse results
> than we thought before.
> After the discussion with [~spmallette], we believe that it would be better
> if detect the unsolvable pattern before the execution.
> {*}In addition{*}, *it would be highly appreciated if someone can reproduce
> and confirm the logic inconsistency in the complex cases. I think it may
> imply other potential issues of the traversal strategies.* And if such logic
> inconsistency still exists using both solvable equivalent patterns, we will
> reduce & report is ASAP.
>
> Best regards,
> Joye Mang
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
