JFYI, we have a configured pre-commit hook

@SemyonSinchenko Thanks for letting me know. It seems that it failed due to the formatting. I pushed the formatted result by the sbt scalafmtAll.

@SemyonSinchenko Thanks for letting me know. It seems that it failed due to the formatting. I pushed the formatted result by the sbt scalafmtAll.

We have quite a strict rules for scalafix... Just add something like case _ => throw new GraphFramesUnreachableException(), should fix it.

Thanks! @SemyonSinchenko.

There are two ways to handle quantified path patterns. Everyone wants to use the pattern such as (u)-[*2..3]->(v), but my approach supports (u)-[*3]->(v) only. The last commit distinguishes fixed-length pattern from the variable length pattern in the parser. The error message includes the limitation that it does not support the variable-length pattern.

There are two ways to handle quantified path patterns. Everyone wants to use the pattern such as (u)-[*2..3]->(v), but my approach supports (u)-[*3]->(v) only. The last commit distinguishes fixed-length pattern from the variable length pattern in the parser. The error message includes the limitation that it does not support the variable-length pattern.

This is excellent. Do you think you know how to implement variable length patterns in another PR? That is a highly desirable, requested feature!

@rjurney I think variable length pattern can be split into fixed-length pattern. (u)-[*2..5]->(v) is (u)-[*2]->(v) or (u)-[*3]->(v) or (u)-[*4]->(v) or (u)-[*5]->(v). Then union all the results is the expected result. Is that right?

I didn't implement the parser side, still tricky, but it is better to see the code to validate what it looks like.

The variable pattern relies on the dataframeunionByName. It is handled within the find method, not the parser side. With that minimal change, now it is working (u)-[*3..5]->(v).

I've added more tests on the edge cases and checked the error message.
Supported:
(u)-[*5]->(v)
(u)-[*3..5]->(v)
(u)-[*10]->(v) // fixed the passer patten to include 0

Not supported:
(u)-[*0]->(v)
(u)-[*..5]->(v)
(u)-[*3..]->(v)
(u)-[*]->(v)

@rjurney @SemyonSinchenko, There were several commits to cover more cases and edge cases. It is not easy to track changes from the original branch. How can I make it easier for your review? Is it better to open a new PR with a new branch?

How can I make it easier for your review? Is it better to open a new PR with a new branch?

At least if we merge the first PR from you, I won't need anymore to approve each CI run :)

@goungoun I would like to mention it again, that we have a pre-commit hooks that run the same set of checks like in CI. You can read about it here: https://github.com/graphframes/graphframes/blob/master/CONTRIBUTING.md#styleguides

@SemyonSinchenko Thanks for your help. By the way, the named edge pattern from the Issue #539 is not supported.
Supported:
(a)-[*1..2]->(b)

Not Supported:
(a)-[e1..2]->(b).
(a)-[e*1..2]->(b).

@goungoun Tbh Im fine with it. There will be another and more Cypher-like API built on top of the PropertyGraphFrame that will cover that. I would like to leave the GraphFrames pattern matching more for motiffs finding instead of MATCH-like queries.

@rjurney what do you think?

@SemyonSinchenko I referenced the Issue #539 and support named edge. If the edge is named e, it will generate _e1, _e2, _e3.

Supported:
(a)-[e*2]->(b)
(a)-[e*1..2]->(b)

Not Supported:
(a)-[e1..2]->(b) //wrong syntax

@goungoun please let us know if you need any support for more contributions! Thanks!

@rjurney @SemyonSinchenko It is merged to the master! Thank you so much!

@rjurney @SemyonSinchenko It is merged to the master! Thank you so much!

Thanks for the contribution!