# Dgraph graphql cascade and first

**URL:** <https://discuss.dgraph.io/t/dgraph-graphql-cascade-and-first/12703>\
**Category:** GraphQL\
**Tags:** graphql, dgraph\
**Created:** [February 9, 2021, 6:06am UTC](https://discuss.dgraph.io/t/dgraph-graphql-cascade-and-first/12703 "2021-02-09T06:06:25Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![machship-bsuryn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/machship-bsuryn/32/5439_2.png) [@machship-bsuryn](https://discuss.dgraph.io/u/machship-bsuryn)\
**Post date:** [February 9, 2021, 6:06am UTC](https://discuss.dgraph.io/t/dgraph-graphql-cascade-and-first/12703/1 "2021-02-09T06:06:25Z")

</div>

I was wondering if this is a bug or I am using it incorrectly.  
I have the following graphql query,  
which I am trying to get all accounts with a client name like ben and limit those results to 10.  
But it seems like the below is getting the top 10 accounts and then cascading via client name.  
So if I have a large list of accounts, the query rarely returns the results I want. I know in this simple example I can invert the query, but I have more complex examples with other filters/multiple cascade filtering.

```auto
query {
  queryAccount(first:10, offset:0) @cascade {
    id
    client(filter:{name:{regexp:"/.*ben.*/"}}) {
      name
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![machship-mm](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/machship-mm/32/3065_2.png) [@machship-mm](https://discuss.dgraph.io/u/machship-mm)\
**Post date:** [February 9, 2021, 7:14am UTC](https://discuss.dgraph.io/t/dgraph-graphql-cascade-and-first/12703/2 "2021-02-09T07:14:31Z")

</div>

Just to provide some examples, this also happens in DQL.

Here is an example GraphQL Schema:

> **GraphQL Schema**
>
> ```auto
> type Upper {
> id: ID!
> name: String @search(by: [regexp])	
> lowers: [Lower] @hasInverse(field: upper)
> }
> 
> type Lower {
> id: ID!
> name: String @search(by: [regexp])
> upper: Upper @hasInverse(field: lowers)
> }
> 
> ```

and here is some example data to use with the `liveloader` feature:

> **RDF Data**
>
> ```auto
> <_:a1> <dgraph.type> "Upper" .
> <_:a1> <Upper.name> "Upper 1" .
> 
> <_:xb> <dgraph.type> "Lower" .
> <_:xb> <Lower.name> "Lower ab" .
> <_:xb> <Lower.upper> <_:a1> .
> <_:a1> <Upper.lowers> <_:xb> .
> 
> <_:a2> <dgraph.type> "Upper" .
> <_:a2> <Upper.name> "Upper 2" .
> 
> <_:xc> <dgraph.type> "Lower" .
> <_:xc> <Lower.name> "Lower abc" .
> <_:xc> <Lower.upper> <_:a2> .
> <_:a2> <Upper.lowers> <_:xc> .
> 
> <_:a3> <dgraph.type> "Upper" .
> <_:a3> <Upper.name> "Upper 3" .
> 
> <_:xd> <dgraph.type> "Lower" .
> <_:xd> <Lower.name> "Lower abcd" .
> <_:xd> <Lower.upper> <_:a3> .
> <_:a3> <Upper.lowers> <_:xd> .
> 
> <_:a4> <dgraph.type> "Upper" .
> <_:a4> <Upper.name> "Upper 4" .
> 
> <_:xe> <dgraph.type> "Lower" .
> <_:xe> <Lower.name> "Lower bdef" .
> <_:xe> <Lower.upper> <_:a4> .
> <_:a4> <Upper.lowers> <_:xe> .
> 
> <_:a5> <dgraph.type> "Upper" .
> <_:a5> <Upper.name> "Upper 5" .
> 
> <_:xf> <dgraph.type> "Lower" .
> <_:xf> <Lower.name> "Lower efg" .
> <_:xf> <Lower.upper> <_:a5> .
> <_:a5> <Upper.lowers> <_:xf> .
> 
> ```

If you apply the schema, then load the data, you should be able to run the following DQL query, where we expect 2 results, but only get 1:

```auto
{
  q(func: eq(dgraph.type,"Upper"), first:2) @cascade {
    uid
    Upper.name
    Upper.lowers @filter(regexp(Lower.name, /.*a.*/)) {
      uid
      Lower.name
    }
  }
}

```

Same result if we query this using GraphQL (expect 2, get 1):

```auto
query {
  queryUpper(first:2, offset:0) @cascade {
    id
    lowers(filter:{name:{regexp:"/.*a.*/"}}) {
      id
      name
    }
  }
}

```

Just through some further research, it appears that there may be other related issues, however, to illustrate our point, we feel that given the following GraphQL (ignoring `@auth` rules):

```auto
query {
  queryAccount(first:10, offset:0) @cascade {
    id
    client(filter:{name:{regexp:"/.*ben.*/"}}) {
      name
    }
  }
}

```

we are really attempting to get the same result as this DQL:

```auto
{
  var (func: type(Client)) @filter(regexp(Client.name, /.*ben.*/)) @cascade {
    Client.accounts {
      var flt1 as uid
    }
  }
  
  accounts(func: type(Account), first: 10) @filter(uid(flt1)) {
    uid
    Account.name
  }
}

```

This request should ensure that we get any clients where the `name` is ‘like’ “%ben%”, ensuring that those clients returned **have** at least 1 account, then using the returned client `uid`s, we can filter the accounts to get the top 10 that match.

We’d use the DQL, but it doesn’t respect the `@auth` directive rules from the GQL Schema.

---

<div class="post-metadata">

**Author:** ![rajas](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/rajas/32/4393_2.png) [@rajas](https://discuss.dgraph.io/u/rajas)\
**Post date:** [February 9, 2021, 9:46am UTC](https://discuss.dgraph.io/t/dgraph-graphql-cascade-and-first/12703/3 "2021-02-09T09:46:26Z")

</div>

This is a known issue. This happens because `@cascade` is a post-processing step.

We are actively working on fixing this.

Related Discuss Posts:

1. [Cascade Directive with Pagination produces unexpected results](http://discuss.hypermode.com/t/cascade-directive-with-pagination-produces-unexpected-results/8862)
2. [Cascade does not work with pagination](http://discuss.hypermode.com/t/cascade-does-not-work-with-pagination/7627)

Related RFC: [WIP: cascade with pagination](http://discuss.hypermode.com/t/wip-cascade-with-pagination/12654)