edge hop should return edge list

[khoale88]

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?

[davidmezzetti]

Do you have examples of what breaks? Would this make the next version 2.0?

[khoale88]

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

[khoale88]

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

[khoale88]

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.

[davidmezzetti]

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.

[j6k4m8]

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.

[davidmezzetti]

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.