# Variable propagation in same query block

**URL:** <https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914>\
**Category:** Dgraph\
**Tags:** kind:question, area:querylang:vars\
**Created:** [August 31, 2020, 5:26am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914 "2020-08-31T05:26:45Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [August 31, 2020, 5:26am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/1 "2020-08-31T05:26:45Z")

</div>

How to get the following query to work? I need to get the region uid under “workflow” to use as a variable for the location region. It doesn’t work as nothing is returned. If I hard code a location it works but wondering why the variable propagation doesn’t work here with the “reg” variable.

I also tried it with uid(val(reg)) and produces the same result.

```auto
{
  invoices(func: type(invoice), first: 5000) @cascade {
    purchase_orders {
      workflows: ~purchase_orders @filter(type(workflow)) {
        reg as regions
        locations {
          regions @filter(uid(reg))
          location_uid: uid
          location: location.name
        }
      }
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![chewxy](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/chewxy/32/4339_2.png) [@chewxy](https://discuss.dgraph.io/u/chewxy)\
**Post date:** [August 31, 2020, 10:40am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/2 "2020-08-31T10:40:39Z")

</div>

Something like this?

```auto
{
  invoices(func: type(invoice), first: 5000) @cascade {
    purchase_orders {
      workflows: ~purchase_orders @filter(type(workflow)) {
        regions { reg as uid }
        locations {
          regions @filter(uid(reg))
          location_uid: uid
          location: location.name
        }
      }
    }
  }
}

```

---

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [August 31, 2020, 12:53pm UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/3 "2020-08-31T12:53:22Z")

</div>

Same issue unfortunately.

---

<div class="post-metadata">

**Author:** ![ppp225](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/ppp225/32/2007_2.png) [@ppp225](https://discuss.dgraph.io/u/ppp225)\
**Post date:** [August 31, 2020, 2:06pm UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/4 "2020-08-31T14:06:32Z")

</div>

When you put the `reg` variable declaration in a separate query block, it works.

```auto
Data:
<_:reg1> <name> "Reg1" .
<_:reg2> <name> "Reg2" .

<_:node1> <name> "Node1" .
<_:node2> <name> "Node2" .
<_:node3> <name> "Node3" .

<_:node1> <child> <_:node2> .
<_:node1> <child> <_:node3> .
<_:node1> <reg> <_:reg1>.
<_:node2> <reg> <_:reg1>.
<_:node3> <reg> <_:reg2>.

Query:
{
  var(func: has(name)) @filter(eq(name, "Node1")) {
    name
    R as reg # works
  }
  q(func: has(name)) @filter(eq(name, "Node1")) @cascade {
    name
    #R as reg # doesn't work
    child {
      name
      reg @filter(uid(R))
    }
  }
}

```

I think both versions should work tho.

---

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [August 31, 2020, 2:10pm UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/5 "2020-08-31T14:10:35Z")

</div>

Ya the separate block works when you are doing a more global collection of regions. In my situation I need it to use the region underneath the workflow type for that specific workflow. So the region UID would be the region edge on its parent workflow.

---

<div class="post-metadata">

**Author:** ![ppp225](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/ppp225/32/2007_2.png) [@ppp225](https://discuss.dgraph.io/u/ppp225)\
**Post date:** [August 31, 2020, 2:15pm UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/6 "2020-08-31T14:15:05Z")

</div>

I see. You’ll probably like my issue then, where I tried to do something similar. [Nested / cyclic filtering not working](http://discuss.hypermode.com/t/nested-cyclic-filtering-not-working/8500)

---

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [September 1, 2020, 1:26am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/7 "2020-09-01T01:26:56Z")

</div>

@chewxy @dmai any other suggestions I can try out to get this to work?

---

<div class="post-metadata">

**Author:** ![chewxy](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/chewxy/32/4339_2.png) [@chewxy](https://discuss.dgraph.io/u/chewxy)\
**Post date:** [September 1, 2020, 10:06am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/8 "2020-09-01T10:06:06Z")

</div>

I have none for now. I’d check with @pawan and @MichelDiz as well

---

<div class="post-metadata">

**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\
**Post date:** [September 2, 2020, 7:19am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/9 "2020-09-02T07:19:59Z")

</div>

> [@nodeworks](#):
>
> Ya the separate block works when you are doing a more global collection of regions. In my situation I need it to use the region underneath the workflow type for that specific workflow. So the region UID would be the region edge on its parent workflow.

I think what you are looking for is local filtering along every path instead of one global filtering. I think it’s not possible currently to do that but I can confirm if you share a small example dataset, the query and the expected response?

---

<div class="post-metadata">

**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\
**Post date:** [September 3, 2020, 4:20am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/10 "2020-09-03T04:20:43Z")

</div>

I have this discussion [Promise a nested block (under construction - I'm still working in the use case)](http://discuss.hypermode.com/t/promise-a-nested-block-under-construction-im-still-working-in-the-use-case/5175) which I have noted some use cases related to Variables in the same block. Dgraph won’t work well with variables in the same block and in different levels of the block if not an aggregation.

I think that is a huge work to analyze and make a decision on the design of the Query System. For now multiple blocks are the only way and can be tricky for some use cases. But I think two blocks for this case (of the topic itself) are acceptable. Something like:

```auto
{
  I as var(func: type(invoice), first: 5000) @cascade {
    purchase_orders {
      workflows: ~purchase_orders @filter(type(workflow)) {
        reg as regions { uid }
      }
    }
  }
    invoices(func: uid(I)) @cascade {
      purchase_orders {
        workflows: ~purchase_orders @filter(type(workflow)) {
          locations {
            regions @filter(uid(reg))
            location_uid: uid
            location: location.name
            }
          }
        }
    }
}

```

Also, internally I have this [http://discuss.hypermode.com/t/improvement-on-the-query-system/8365](http://discuss.hypermode.com/t/improvement-on-the-query-system/8365)

---

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [September 3, 2020, 4:32am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/11 "2020-09-03T04:32:59Z")

</div>

Hey @MichelDiz,

How would that work in a two block query if the variable should be from the corresponding parent workflow? Wouldn’t the “reg” variable just be a list of regions that occurred in the var block? Using the query you pasted above I get results that have this:

 ![Screen Shot 2020-09-03 at 12.31.42 AM](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/a/ae806c4594b8acd2a242a9e923446e89b519fb6b.png)

Whereas the location region should match the workflow region and if it doesn’t then it shouldn’t be included.

---

<div class="post-metadata">

**Author:** ![MichelDiz](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/micheldiz/32/11873_2.png) [@MichelDiz](https://discuss.dgraph.io/u/MichelDiz)\
**Post date:** [September 3, 2020, 4:37am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/12 "2020-09-03T04:37:13Z")

</div>

You right, I have just noticed that after writing - also I have noted that behave in my on old tests. The only way to “control” this collateral result is by using pagination (e.g `q(func: type(Person), first:1)` plus `offset` usage). Which isn’t good for your case.

Maybe we should have a new type of var that holds the values block to the next block or have loops. Or supporting the filtering in the same single block and levels of a single block.

---

<div class="post-metadata">

**Author:** ![nodeworks](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/nodeworks/32/3637_2.png) [@nodeworks](https://discuss.dgraph.io/u/nodeworks)\
**Post date:** [September 3, 2020, 4:42am UTC](https://discuss.dgraph.io/t/variable-propagation-in-same-query-block/9914/13 "2020-09-03T04:42:04Z")

</div>

Ya I think that would be the only way to satisfy this use case. In the meantime I can just loop through the results client-side and remove any non-matching locations.
