TropicalPenguin commented on issue #330:
URL: https://github.com/apache/age/issues/330#issuecomment-1283474368
> Btw, as it is always possible that we got something incorrect or
overlooked something, I ran your query on Neo4j to make sure that our
implementation conforms with theirs and it also returned zero rows.
Plot twist! Huh. This is interesting. I tested these in RedisGraph before
creating this issue. And in RedisGraph, these commands give me the following
result:
```
127.0.0.1:6379> GRAPH.QUERY test "CREATE (a:A)-[:incs]->(:C),
(a)-[:incs]->(:C) RETURN a"
```
```
1) 1) "a"
2) 1) 1) 1) 1) "id"
2) (integer) 0
2) 1) "labels"
2) 1) "A"
3) 1) "properties"
2) (empty array)
3) 1) "Labels added: 2"
2) "Nodes created: 3"
3) "Relationships created: 2"
4) "Cached execution: 0"
5) "Query internal execution time: 6.650151 milliseconds"
```
```
127.0.0.1:6379> GRAPH.QUERY test "MATCH (a:A) WITH a OPTIONAL MATCH
(a)-[:incs]->(c) RETURN c"
```
```
1) 1) "c"
2) 1) 1) 1) 1) "id"
2) (integer) 1
2) 1) "labels"
2) 1) "C"
3) 1) "properties"
2) (empty array)
2) 1) 1) 1) "id"
2) (integer) 2
2) 1) "labels"
2) 1) "C"
3) 1) "properties"
2) (empty array)
3) 1) "Cached execution: 0"
2) "Query internal execution time: 6.739759 milliseconds
```
```
127.0.0.1:6379> GRAPH.QUERY test "MATCH (a:A) WITH a OPTIONAL MATCH
(a)-[:incs]->(c)-[d:incs]-() WITH a,c,COUNT(d) AS deps WHERE deps=1 RETURN
c,deps"
```
```
1) 1) "c"
2) "deps"
2) 1) 1) 1) 1) "id"
2) (integer) 2
2) 1) "labels"
2) 1) "C"
3) 1) "properties"
2) (empty array)
2) (integer) 1
2) 1) 1) 1) "id"
2) (integer) 1
2) 1) "labels"
2) 1) "C"
3) 1) "properties"
2) (empty array)
2) (integer) 1
3) 1) "Cached execution: 0"
2) "Query internal execution time: 2.113974 milliseconds"
```
It seems you're right about the Neo4J behaviour though. I was able to get
the behaviour there (and on AGE) that I was expecting by separating that clause
in two:
`MATCH (a:A) WITH a OPTIONAL MATCH (a)-[:incs]->(c) WITH c OPTIONAL MATCH
(c)-[d:incs]-() WITH c,COUNT(d) AS deps WHERE deps=1 RETURN c,deps`
Given the possibility of such a workaround (thanks for making clearer the
source - whether limitation or intent - of the failure, because it let me know
how to approach one), I'm now less concerned about the difference in behaviour
from RedisGraph.
Still, the fact that is supported in some Cypher implementations raises some
interesting questions about your other observations.
> It is not a limitation, it depends on the graph given and the "technical"
definition of a path.
I wonder from this if the implementation based on sparse matrices makes the
evaluation of such structures more natively handled than whatever approach
Neo4J is using...
> But, just for a moment, think of the implications of allowing an edge to
be reused. Since vertices can be reused, that would cause endless loops.
Yeah, I can definitely see the possibility of an implementation running into
cycles, however, intuition (and the fact that it can be evaluated by at least
one implementation) would suggest that there are sufficient constraints
specified in the query to infer when to stop traversing.
But especially given that a major vendor doesn't handle this, I'm now
totally content if this isn't treated as a priority.
Would you like me to close this issue?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
