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

Filtering and paginating on @cypherNode and @cypherRelationship #3

Open
2 of 3 tasks
a-type opened this issue May 31, 2019 · 4 comments
Open
2 of 3 tasks

Filtering and paginating on @cypherNode and @cypherRelationship #3

a-type opened this issue May 31, 2019 · 4 comments
Assignees
Labels
blocked Blocked by another problem (probably Cypher language spec enhancements) enhancement New feature or request
Milestone

Comments

@a-type
Copy link
Owner

a-type commented May 31, 2019

Connecting directives need more control over how the data is queried.

Research:

  • What clauses are allowed in list projections?

Implement:

  • Matching based on arbitrary user defined parameters
  • ORDER BY / SKIP / LIMIT

Questions:

  • Is there any point to these directives, or could @cypher just be expanded to work in nested scenarios?
@a-type a-type added the enhancement New feature or request label May 31, 2019
@a-type a-type added this to the v1 milestone May 31, 2019
@a-type a-type self-assigned this May 31, 2019
@a-type
Copy link
Owner Author

a-type commented Jun 1, 2019

Research results: only WHERE is allowed in list projections (opencypher/openCypher#202).

Ordering, skipping, limiting will all be blocked on better sub-query support (opencypher/openCypher#217), but if that gets added to the spec, the library will get a major feature boost!

A fake pagination could be introduced by slicing up the list comprehension, but it would not be lazy, and without ordering it doesn't feel very useful. List ordering currently unsupported (opencypher/openCypher#190).

Alternate approach to achieving nested paginated fields: manually combine subqueries by chaining WITH blocks then pull them back into a final map projection (yikes!)... might end up doing it. Query perf might be worse due to eager operations, but I think that's going to be unavoidable if the schema uses pagination at each field level anyways.

@a-type
Copy link
Owner Author

a-type commented Jun 1, 2019

Next steps:

@a-type a-type added the blocked Blocked by another problem (probably Cypher language spec enhancements) label Jun 1, 2019
@SpaghettiFactory
Copy link

This is marked as blocked. What is needed in order to implement this?

@a-type
Copy link
Owner Author

a-type commented Jun 1, 2020

Hi @SpaghettiFactory ! I admit this project isn't really on my radar anymore, but here's how I remember it -

Basically, without first-class subqueries, Cypher can't really support nested pagination. I don't quite remember the specifics, but I believe this library uses field projections to accomplish nested structures, and field projections don't allow for standard pagination constructs to be used (or at least, not to the extend that they could enable cursor-based pagination).

This issue was related, and is still open - opencypher/openCypher#217

Limitations with Cypher for this use case in particular was, as I recall, why I ended up shopping around for different graph databases to use behind GraphQL. I had a bit of success with ArangoDB, which does support subqueries in its query language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Blocked by another problem (probably Cypher language spec enhancements) enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants