[
https://issues.apache.org/jira/browse/TINKERPOP-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miracy Cavendish updated TINKERPOP-2961:
----------------------------------------
Description:
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
was:
Hi all! From
[Discord|https://discord.com/channels/838910279550238720/1064868348925583442/threads/1117146194666332250].
We noticed that in some case 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 them results in a 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
detecting the unsolvable pattern before the executing.
{*}In addition{*}, *it would be highly appriciated if someone can reproduce and
confirm the logic inconsistency in the complex cases. I think it may imply
other potential issues of the traversal stratgies.* And if such logic
inconsistency still exist using both solvable equivalent patterns, we will
reduce & report is ASAP.
Best regards,
Joye Mang
> 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
> 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)
