Hello, I can’t seem to get a count working when I’m recursing through the graph and applying a filter on the node I want to issue the count on. I have a depth of 10 set on the recurse. Test 1: I started with: count(myNode) myNode @filter(NOT eq(name, "Bob")) Result: I found that the query was …

I think you should consider doing the filter at the root of the query instead. I do not think the order matters here, you need to specify filter twice as you have in the final version of the query. If you share the full query, maybe it is possible to simplify it. Hope that helps.

[image] rahst12: Result: I found that the query was counting every “myNode” including the ones with name John. This is expected. This is an edge count. So line 1 and 2 are independent. [image] rahst12: I changed the count to include the filter: This is not the recommended way. We don’…

Hi @amanmangal and @MichelDiz , Thanks! Clearly the filter is needed to get the right counts here, so just focusing on the order - above vs. below the node. [image] amanmangal: If you share the full query, maybe it is possible to simplify it. I can’t share my query, but I can replicate it. …

So, your problem is exclusive to Recurse query. Without it any order doesnt matter. Understand that Recurse is a kind of automation. Where it will continue expanding according to the query body (list of predicates) given. So order can influence in this case. And results can be unforeseen for each c…

Hi @MichelDiz , Thanks for the confirmation that order does matter in DQL queries, when @recurse is being used. I’d love to understand a little more why that’s the case. This seems like a pretty big bug - it was at least quite surprising to us. I haven’t scoured all the DGraph documentation, but …

[image] rahst12: Could you explain a little more why order matters in this case? I can’t get to the level of detail because I didn’t create that code and its algorithm. But I know that it recursively applies everything in the body and can end up influencing other edges that have some relation…

[image] MichelDiz: But this is normal, recurse is a type of query that can generate unexpected results. You shouldn’t use recurse as a source of truth. But to explore its objects. Don’t do fancy things with it. Always create predictable queries. Or you will have problems. We’re fully explorin…

[image] rahst12: Is there a better practice to do this that’s more reliable than @recurse? Use normal queries. Well defined queries. No recurse I mean. [image] rahst12: what would you consider fancy that we should stay away from? Not using filters in a count or even recurse. You can u…

Hey @MichelDiz , I’m starting learn the vocab a bit better now.. query root, etc - thanks. I created the examples queries above to closely mimic the queries we’re performing on a much larger DGraph. I needed them in an easily repeatable way to illustrate the challenges. A couple questions/comment…

[image] rahst12: Are there query performance considerations when querying all nodes of a particular type and then applying the filter? Yes. If you have a huge Tablet indexation for the Type. This could potentially increase latency. There are ways to mitigate this. [image] rahst12: The re…

Does order in a DQL query matter?

Users Dgraph

MichelDiz (Michel Diz) February 14, 2023, 7:24pm 14

BTW check this out

Topic		Replies	Views
Recurse after filter Dgraph	10	1428	November 2, 2018
Count Queries in GraphQL GraphQL rfc , area:graphql	22	21070	March 19, 2021
Inability to do simple GraphQL query filtering on node / edges like other GraphQl BaaS'es offer? Dgraph Cloud / Slash GraphQL kind:question	18	3942	May 20, 2021
So this recursive query, it takes 2 to 8 seconds, did I write it wrong?Or what can I do to make the query faster, how can I index it？ Dgraph discussion , kind:question , dgraph	7	687	January 6, 2021
RFC: Nested Filters in GraphQL Dev graphql , rfc	39	9376	March 31, 2024

Does order in a DQL query matter?

Related topics