Open Krejtcha opened 2 years ago
Hi, just wanted to ask if somebody had a look on this issue? I can answer your questions if you have any.
The example you provided is an edge case that shows the limits of the chosen approach. I think, to get the example working, you have to collect all the required information by yourself, if they are not provided in the context.
I believe that it should be configurable for each GraphQL type do define what data will be always fetched from neo4j to provide sufficient context for additional custom Data Fetchers.
This is nothing we will add in the near future. The current focus is on harmonizing the API with the one from the Javascript version.
I understand that this is no priority, but I do not think it is an edge case and I would like to understand what you mean by "you have to collect all the required information by yourself, if they are not provided in the context". When using custom data fetchers you fetch the data based on the parent context (you need at least the id in order to be able to calculate something), but here the parent context is created by this library which creates it based on the GraphQL query provided by the user. This means that if the user does not query for the needed context, the cypher provided by the library will not fetch the context either and the custom data fetcher therefore does not have any context to work with. I do not know how I should collect the required context by myself. The only thing I can think of is to augment the user provided GraphQL query to contain the fields needed for the context (and later remove those fields from the result) or to augment the cypher generated by the library to include the fields needed for the context (which I do not think is the way to go). Maybe I am missing something, could you explain how you meant it, how do I collect the needed context by myself?
There are two use cases:
@context
, feel free to suggest a better name)In the Javascript-API a new @computed
directive is used to solve this kind of issue. So this will be fixed after the API-Alignement is implemented (which I'm currently working on).
Describe the bug
Right now the library generates the cypher query based on the provided GraphQL query only fetching the attributes that were requested from neo4j. This might seem like a good idea when it comes to performance (why fetch the whole node if just a couple of attributes were requested). The problem occurs when using additional custom Data Fetchers. These Data Fetchers can be used to run custom cypher queries that would not be supported by the @cypher directive or running any computation code, accessing other databases ... but in order to do that they need context. This context should be provided by the
env.getSource()
method where all the parent data should be present. In most cases you will need theid
of the parent to be able to do any additional computation. But in this case the parent contains only the data that were requested from neo4j which is wrong.In the example below the
javaData.name
relies on thetitle
and if this is not requested it will not be in the parent thusjavaData.name
will have the value"test null"
which is wrong.Test Case
Modify the content of the class: https://github.com/neo4j-graphql/neo4j-graphql-java/blob/master/examples/dgs-spring-boot/src/test/kotlin/org/neo4j/graphql/examples/dgsspringboot/datafetcher/AdditionalDataFetcherTest.kt to the following code:
and run the test.
Additional context
I believe that it should be configurable for each GraphQL type do define what data will be always fetched from neo4j to provide sufficient context for additional custom Data Fetchers. This way the necessary data will be always fetched and the additional custom Data Fetchers will be satisfied and will be able to do their computation and the rest of the data will be fetched only if requested by the QraphQL query for better performance. The
graphql-java
library should then remove data that was not requested from the result returning only that the user asked for with the benefit that the additional custom Data Fetchers were able to do their computation and return the correct result.Note that this modification will break the
Translator
approach where there is no postprocessing of the fetched data thus the result will contain also the data needed for satisfaction of the additional custom Data Fetchers and not only what the user asked for.