Currently we are launching two queries to dgraph one through the /graphql endpoint filtering a node by id and it does not respond data, however if we launch the query in dql format to the /query endpoint we get results.
Dgraph version: 21.12.0
Can you share the queries?
in dgraph /query:
{
find_id(func: uid(0x8ee73d)) {
uid
dgraph.type
expand(_all_)
}
}
in dgraph /graphql:
query Query($filter: NodeTempFilter) {
queryNodeTemp(filter: $filter) {
id
name
}
}
{
"filter": {
"id": ["0x8ee73d"]
}
}
Looks fine, share your GraphQL Schema.
in the input schema to dgraph:
type NodeTemp{
id: ID!
name: String
description: String
}
the output filter shows this:
input NodeTempFilter {
id: [ID!]
has: [NodeTempHasFilter]
and: [NodeTempFilter]
or: [NodeTempFilter]
not: NodeTempFilter
}
In general inputs are for mutations only.
Can you try without the params(filter) and also with the param but without gql variable?
Is the data okay? does it has the prefix NodeTemp? for example NodeTemp.name and NodeTemp.description?
Sorry, I sent the SDL I got from the Dgraph, but if I look at it natively in the Dgraph I can see the node prefix, on the other hand, I didn’t quite understand the test to run, would it be to launch the query without the filter parameter? we talk about the query that goes to /graphql?
Test this:
1 This should show all objects
query Query {
queryNodeTemp {
id
name
}
}
2 this is to test if the variable was bad formed
query Query {
queryNodeTemp(filter: {
id: ["0x8ee73d"],
}) {
id
name
}
}
In the first case it returns some data but not the one I am particularly filtering.
In the second case, applying the filter does not return any data either.
But if I launch the query from the postman to the url /query with the filter of that value if I get a record back
So, maybe the problem is your data. Share it, as it is. There’s no other situation I can see.
Is there a way in which the data is badly created and can only be seen from a DQL query? I also suspect that this could be the problem but it is strange that in DQL it responds and graphql does not.
A few. If you don’t add the prefix, if you add the wrong prefix, if you don’t add the dgraph.type or the wrong type that is not in GraphQL schema. And possible others.
In that sense, it is not advisable then to use the /graphql endpoint to create records in dgraph? because all our data has been created by that path and likewise when I query by /query I can see that the type is associated to my node.
Quite the opposite. If you are going to use GraphQL. The ideal is always to use mutation in GraphQL. Because it parses the object correctly. But if you try to do the same via DQL/RDF. You might end up making mistakes because you don’t know the model well.
The problem is something else. Not GraphQL, I’m 100% sure of that.
one last question about this same behavior, in the real scenario we see that the user can reach our node jumping from another one, example: from node1 I make queries and when I get the edges there if I can see my node2, which does not happen when I consult directly to node2, this could be due to the same data issue you mentioned?
This sounds another thing too. Are you able to find the 0x8ee73d traversing other nodes?
And yes, both in GraphQL and DQL, a user with free access will be able to explore other nodes. To mitigate this you must use Auth directive and set up permissions. Or don’t give free access to your GraphQL perhaps. But auth is free, you can set up an authentication provider with it.
Yes, from another node I can get to the information of my node: 0x8ee73d, but when I consult it directly we can not see anything of that node, for the moment I think we will continue to investigate the error and if anything new I comment in this ticket for the information of the community, thank you very much for your help and your support in this ticket.
What is the type in 0x8ee73d dgraph.type predicate?
this would be the example
"data": {
"find_id": [
{
"uid": "0x8ee73d",
"dgraph.type": [
"NodeTemp"
],
"NodeTemp.description": "XXXX",
"NodeTemp.name": "XXXX"
}
]
}
