[
https://issues.apache.org/jira/browse/TINKERPOP-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752114#comment-17752114
]
Stephen Mallette commented on TINKERPOP-2961:
---------------------------------------------
regarding:
{quote}After creating the graph based on the statements provided in the Jira
attachment, I obtained a result. Then, I deleted all the nodes and recreated
the same graph. Surprisingly, when I ran the same query again, it returned a
different result. This inconsistency in the query results may suggest a
potential bug in the schema creation process. I would appreciate any assistance
in reproducing and confirming this issue.{quote}
i'm not sure what's happening exactly. i can reproduce this issue with the
default algorithm for {{match()}} seems which is {{CountMatchAlgorithm}}. If I
switch to the more simplistic {{GreedyMatchAlgorithm}} i don't see the counts
changing between graph regenerations:
{code}
gremlin>
g.withStrategies(MatchAlgorithmStrategy.build().algorithm(org.apache.tinkerpop.gremlin.process.traversal.step.map.MatchStep.GreedyMatchAlgorithm.class).create()).V().match(
......1> __.as("n2").out().as("n1"),
......2> __.as("n2").in().in().in().both().in().as("n1"),
......3> __.as("n2").both().in().in().as("n3"),
......4> __.as("n3").in().both().as("n2"),
......5> __.as("n4").both().out().out().out().out().as("n2"),
......6> __.as("n2").out().both().in().as("n4"),
......7> __.as("n3").both().as("n4"),
......8> __.as("n1").in().both().both().both().as("n5")
......9> ).dedup().count()
==>306701
{code}
i'm really not sure where the bug might be with this because the data and the
query are so complex. i'd probably recommend switching to the "greedy"
algorithm since it seems to produce deterministic results. Since "greedy" is a
workaround and {{match()}} is in need of more serious changes that would make
this issue of no concern, I'm inclined to not dig into this any further and
close.
> 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)
