[jira] [Commented] (TINKERPOP-2961) Missing exceptions for unsolvable match pattern, which may lead to logic inconsistency

["Stephen Mallette (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TINKERPOP-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17751194#comment-17751194 ] 

Stephen Mallette commented on TINKERPOP-2961:
---------------------------------------------

It was additionally noted that:

> 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.

> 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)