Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add experimental draft support for GPML-style graph query #652

Merged
merged 5 commits into from
Jun 28, 2022
Merged

Conversation

jpschorr
Copy link
Contributor

@jpschorr jpschorr commented Jun 24, 2022

Part of the exploration of #689

This adds draft parser/AST support for a subset of GPML as outlined by Graph Pattern Matching in GQL and SQL/PGQ. The use within the grammar is based on the assumption of a new graph data type being added to the specification of data types within PartiQL, and should be considered experimental until the semantics of the graph data type are specified.

This adds support for parsing:

  • basic and abbreviated node and edge patterns (section 4.1 of the GPML paper)
  • concatenated path patterns (section 4.2 of the GPML paper)
  • graph patterns (i.e., comma separated path patterns) (section 4.3 of the GPML paper)
  • AST support for path quantifiers (section 4.4 of the GPML paper)
  • AST support for pre-filters (section 5.2 of the GPML paper)

TODO:

  • path variables (section 4.2 of the GPML paper)
  • parsing support for path quantifiers and group variables (section 4.4 of the GPML paper)
  • path pattern union and multiset (section 4.5 of the GPML paper)
  • conditional variables (section 4.6 of the GPML paper)
  • graphical predicates (section 4.7 of the GPML paper)
  • restrictors and selector (section 5.1 of the GPML paper)
  • pre-filters and post-filters (section 5.2 of the GPML paper)
  • aggregats of unbounded variables (section 5.3 of the GPML paper)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Copy link
Contributor

@am357 am357 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM, added some minor comments.

am357
am357 previously approved these changes Jun 27, 2022
Copy link
Member

@alancai98 alancai98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good to me. Have some nits and some questions related to how some of the nodes/edges are being parsed.

@@ -585,7 +590,7 @@ internal const val DIGIT_CHARS = "0" + NON_ZERO_DIGIT_CHARS

@JvmField internal val E_NOTATION_CHARS = allCase("E")

internal const val NON_OVERLOADED_OPERATOR_CHARS = "^%=@+"
internal const val NON_OVERLOADED_OPERATOR_CHARS = "^%=@+~"
internal const val OPERATOR_CHARS = NON_OVERLOADED_OPERATOR_CHARS + "-*/<>|!"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, just noticed the OPERATOR_CHARS variable isn't used anywhere. Can it be removed?

Comment on lines +3580 to +3594
} catch (e: ParserException) {
null
}
patterns.add(nodeLeft)
do {
val edge = try {
parseEdge()
} catch (e: ParserException) {
null
}
patterns.add(edge)
val nodeRight = try {
parseNode()
} catch (e: ParserException) {
null
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do these return null when there's a ParserException?

Co-authored-by: Alan Cai <caialan@amazon.com>
@jpschorr jpschorr requested review from am357 and alancai98 June 28, 2022 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants