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