Hey @iluminae, since @cascade is a post-processing step, it doesn’t know about the pagination limit at the top level since a node can be filtered out due to some children node being filtered out so the first approach suggested by you cannot be implemented.
However, the second approach can optimize the current solution which is equivalent to having has filters on each level along with the @cascade directive.
So the optimized query will be:-
q(func: type(Device), first:2) @cascade(myEdgeThatIsUsedToFilter) @filter(has(myEdgeThatIsUsedToFilter)) {
...fields
has_object @filter(type(Object)) (first:2) @filter(has(myEdgeThatIsUsedToFilter)) {
...fields
has_indicator @filter(type(Indicator)) (first:2) @filter(has(myEdgeThatIsUsedToFilter)) {
...fields
}
}
}
You can use this query and tell us about the latency and correctness of the result. Meanwhile, we discuss internally about the possible optimisations to it.