Cascade does not work with pagination

Issues Dgraph
,
#1

I expect pagination to work in conjunction with cascade but that does not seem to be true (at least in GraphQL).

I have a query that returns around 15K nodes and want to get the first 5 that match the @cascade directive as well. The result is 0. However if I remove the pagination limit then I get all the ones that match cascade.

I believe the problem is that pagination happens before the cascade directive on the rood of the query. Is there a way to reverse this order? I don’t see any need why someone would want to paginate and then apply a cascade directive :thinking:

This will return all of the completed Tasks:

query {
  queryTask @cascade {
    name
    completed
  }
}

This should return the first 5 completed Tasks, but it instead returns an empty set:

query {
  queryTask(first: 5) @cascade {
    name
    completed
  }
}

I understand for performance that pagination reduces the load much faster then cascade does, but I do not believe that is the understood effect. This will probably be a pain to fix and cause performance issues :frowning:

Dgraph graphql cascade and first
Dgraph October Community Call
Filter interface by type
Dgraph Community Call on Aug 13, 2020
FOREACH func in DQL (loops in Bulk Upsert) VOTE!
#2

I did test on Dgraph in Ratel and got similar results. So this issue is not specific to the graphql endpoint.

Edit: I also just read through the docs and while one could put this limitation together it is not explicitly stated anywhere that I found that these two used together provide odd results.

I was really looking forward to use @cascade more after it gets parameterized, but will not be able to unless there is someway to control pagination after cascade.

Pagination allows returning only a portion, rather than the whole, result set. This can be useful for top-k style queries as well as to reduce the size of the result set for client side processing or to allow paged access to results. - https://dgraph.io/docs/query-language/#pagination

With the @cascade directive, nodes that don’t have all predicates specified in the query are removed. - https://dgraph.io/docs/query-language/#cascade-directive

^ This leads to the understanding pagination first then with those results do a cascade.

Cascade Directive with Pagination produces unexpected results
#3

Yeah, this doesn’t look right. @pawan, @Paras you’ve both worked in here recently, can you provide some insight.

1 Like
#4

This is because cascade is a post processing step. @pawan , right?

1 Like
#5

yeah, that is right. @cascade is a post processing step so it may exclude some nodes which were part of the paginated result. This should qualify as a bug in Dgraph and we can look into how to fix it. Feel free to open a bug @amaster507

1 Like
#6

Done. Thank you!

1 Like
#7

The bug that was opened for this on github circles back to this forum message. Is there another bug that is tracking this issue. This is a blocker for me, anyone else?

1 Like
#8

Sorry @matthewmcneely, this one fell through the cracks in the GitHub to Discuss migration. I have marked this as accepted and we’ll look into working on it next month.

2 Likes
#9

@minhaj has started working on this and should have a fix for it soon. I expect this to be fixed for the 21.03 release.

1 Like
#10

While we are working on solving this issue, here is an alternate way to do this query which works well for a single level. We have recently added support for has to take a list of arguments. The query below should have the same effect as @cascade.

query {
  queryTask(filter: {input: {has: [name, completed]}}, first: 5) {
    name
    completed
  }
}
1 Like
#11

This has been fixed in the master. Please look at this PR.

1 Like