grand-cypher
grand-cypher copied to clipboard
aplbrain
edge hop should return edge list
To better follow Neo4j cypher specs, grand-cypher can check and return edge hops as following.
| edge hop value | return type | description | error on filter or return |
|---|---|---|---|
| r*0 | [] | empty list to return r | Type error: Cannot access property 'weight' on a list |
| r*1 | {} | attributes of the edge or value of a single attribute | |
| r*2 | [{}, {}] | attributes of the edge | Type error: Cannot access property 'weight' on a list |
| r*0..2 | [], {}, [{}] | depending on what are the real matches of r | depending on what are the real matches of r |
This will make more sense to implement operator like any, all, collect on edge.
This might lead to some backward incompatible.
Hi @j6k4m8 @davidmezzetti what do you think?
Do you have examples of what breaks? Would this make the next version 2.0?
Right now, edges is returned as r*1 regardless hop. The where condition is checked against the direct edge from A to B, which is not correct as well. I will give concrete examples later
This should be some changes I can recall
| edge hop value | return statement | old return value | new return value | filter statement | old fiter result | new filter result |
|---|---|---|---|---|---|---|
| r*0 | r | None | [] | |||
| r*0 | r.name | None | Type error: Cannot access property 'weight' on a list |
|||
| r*1 | r | [{name: kle}] | {name: kle} | |||
| r*1 | r.name | kle | kle | |||
| r*2 | r | [{name: kle}] | [{name: kle}, {name: josh}] | |||
| r*2 | r.name | kle | Type error: Cannot access property 'weight' on a list |
|||
| r*0 | r.name == 'kle' | SKIP | Type error: Cannot access property 'weight' on a list |
|||
| r*1 | r.name == 'kle' | OK | OK | |||
| r*2 | r.name == 'kle' | OK but WRONG | Type error: Cannot access property 'weight' on a list |
the project current deally with multigraph in a very hard-to-understand way. There is Aggregated edge attribute function to treat multi edges between 2 nodes the same, or some other stuff I don't understand yet.
According to neo4j, each edge is treat as a separated match. I think I am going to make it that way. I believe grandiso isomorphic already treat it that way.
I'll defer to you and @j6k4m8 on this and the overall API.
From my standpoint, I've been running with the spec as is for a while now. While the graph component isn't a huge part of TxtAI, making breaking changes will have impacts, especially for users who directly submit Cypher queries.
With all that being said, if you guys feel strongly that things need to be broken to be fixed, I'll make it work from my end.
Thank you guys, this is super helpful context!
Would this make the next version 2.0? ... making breaking changes will have impacts
According to neo4j, each edge is treat as a separated match.
My take here is that there are two guiding principles for this project: First, that we should try to approximate the Cypher spec as closely as possible, and second, that we should try to avoid breaking things for existing users.
This will absolutely necessitate a major version release so that we don't surprise any consumers of this library. But I do feel strongly that we should get back to the Neo4j behavior / OpenCypher spec — writing a similar-but-different query language would be very bad for fragmentation.
All good with me.
Hopefully, for any breaking changes we can just note it somewhere. That will help me either work around it in my code or let downstream users know in cases I can't.