Dgraph DQL Tour

Var Blocks

Query Variables in another query block I

Let’s take a second to think about that last query. The variable JC_actor evaluated to all actors in any Jane Campion film. No matter where we use it, it’s the full set.

That’s the key to using Dgraph’s variables correctly: understand that they are global in the sense that they evaluate to all nodes that could match that edge in the query, not local in the sense that would evaluate to different results for each Jane Campion film.

We can also use query variables in another query block, both as the nodes the root filter matches and in internal filters.

Peter Jackson often appears in his own films, mostly in the background or just a glimpse, but he’s there. The query shows all films that Peter Jackson has both directed and appeared in.

Explaining Query:

The first block looks for any node that has “Peter” and “Jackson”. Without Cascade, this query could return homonyms as “Sam Peter Jackson” among others. The secret of cascade is that when using “director.film” in the query body. It becomes a query parameter. That is, this query will only return some “Peter Jackson” who is a director. And in our database, there is only one Peter as director.

In the second block we use the entities (in this case, only one Peter will return). We applied Cascade again, to guarantee constraints on the query. That is, we eliminate those nodes that Peter Jackson was not an actor, and the films to which he does not have the predicate “name@en”.

5.4 Query Variables in another query block I