Issue running "RETURN graphql.schema()"
I get this error when running the command "RETURN graphql.schema()"
Neo.ClientError.Procedure.ProcedureCallFailed: Failed to invoke procedure graphql.schema: Caused by: java.lang.IllegalArgumentException: Invalid type org.neo4j.values.storable.PointValue
in Enterprise Edition neo4j .
I have loaded the graphql plugin jar under plugins
neo4j-graphql-3.5.0.3.jar
and using the
neo4j-enterprise-3.5.5
Hi,
this is shortcoming of the current plugin, it doesn't support spatial/datetime yet.
But we'll have support for that in one of the next releases when the neo4j-graphql-java library gets it which we expose via /graphql/experimental
@jexp can you elaborate on this? We have started seeing this error in our logs recently when running queries, but have been successfully using distance-based filtering for several months. Calling graphql.schema() doesn't return any errors though.
Our plugin version is 3.5.0.3
I'm not 100% sure but it sounds like a issue with the graphql schema generated from the graph not one that's submitted.
Do you run distance functions via @cypher directive ?
We're working to add the datatypes to https://github.com/neo4j-graphql/neo4j-graphql-java and then use that library as base for the plugin.
@jexp appreciate your fast response. We run neo4j as a cluster using kubernetes, and we've been experimenting with scaling up the number of replicas. When a new replica starts, it grabs the daily backup via initContainer and extracts that, then syncs the remaining changes from the core servers. Are you saying that this isn't enough for the new replica to support the /graphql endpoint, and we need to submit the schema to the leader (which propagates out to the replica) anytime a new replica is added?
Hmm the schema is part of the backup, but I don#t know how you syncs the remaining changes from the core servers. As it's not stored in a way that e.g. cypher can access.
I'd think you'd run a causal cluster on k8s using something like our helm charts that automatically propagate all changes?
Once a new replica has used the daily backup to get its data 99% ready, it joins the cluster and receives any missing changes (since the backup) from the core servers via catchup protocol. That's what I was referring to by syncs the remaining changes from the core servers, we're using the process outlined by David Allen here
But it sounds like schema changes cannot be synced to replicas via catchup, is that correct? In which case we need to look at resubmitting the schema to the leader after each new replica is created?
@jexp just thinking more broadly about our issues with schema management - would the Javascript library & GrandStack be a better choice for our setup here, where we need GraphQL querying but also use a dynamic, scalable neo4j cluster? It seems like in the GrandStack model, the schema lives outside of the database, whereas with the plugin the schema is run inside of it?
Yes that might be easier.
The plugin has to store the schema somewhere.
I don’t know why it wouldn’t sync it across a causal cluster. After all we store the schema in the graph.
Not sure what the remainder of your stack looks like. The js implementation is also a great option. We’re also working on the java/jvm one.