Oops I forgot to include the variables here but I definitely had them, which I ran and it gave me no results.
I looked through that search filtering link prior to posting and noticed that all the examples has filtering at the highest level (i.e. at the getHuman level), which I’m missing here, I don’t know if that’s the problem. I also took out the cascade and still no results.
Another thing is I’m running this query on the Dgraph Cloud ui, I don’t know if that also means anything.
Yeah that one works because it has selection at the highest getAuthor level (id: "0x1"). That example gives all of that particular author’s posts that belong to GraphQL. It would be analogous to me needing to get all pets of a type from a specific Human.
My use case is more of getting all Humans that have a specific type of pet. It would be analogous to getting all authors that have GraphQL posts. i.e. if we were to follow the schema given in the example, it would (in my head) look like this.
getAuthor {
name
posts(filter: {
title: {
allofterms: "GraphQL"
}
}) {
title
text
datePublished
}
}
}
I have what I think is the simplest non-working schema/query in my first post, but if I can simplify it more do let me know.
Again, the query is not your problem. Post exactly your simplest query schema exactly where you have the problem without leaving anything out. Maybe example data too so we can replicate the problem.
Are you using the data studio or an app?
It may be your @auth directive as I said earlier. We don’t have all the the information.
I’m not entirely sure what you mean by the simplest query schema. Is what I posted not the simplest schema?
I’m using the online Dgraph cloud.
I don’t see the mention of the @auth directive, did you mean the cascade directive? I took that out and still no results.
EDIT: So I know it’s possible via queryHuman but the problem is that I have a really large data set so the query one takes forever and usually times out. Maybe I just need to optimize my query instead?
If you have a bunch of records, @cascade is going to read all of them anyway, and then filter those out. It would be quicker to stick with DQL. I would suggest you do a custom dql query for your use case.