One of the things that made me think about uid_in needing improviment was the fact that every time we update the Play Dgraph binaries. All UIDs are changed, thus breaking all examples in Docs that use hand-defined UIDs.
So, one idea would be to use the uid_in target as a variable (hand-defined). However, Dgraph does not support rendering UIDs into numbers or strings.
Before continue, here some example of users complaining about uid_in
{
var(func: uid(0x0)){
a as math(637870) # this will be converted to hex internally.
}
caro(func: eq(name@en, "Marc Caro")) {
uid
name@en
director.film @filter(uid_in(~director.film, val(a)) ) {
# uid_in accepts val()
name@en
}
}
}
I have two ideas to solve this. One simply supports uid_in value variables natively, and the other is adding a feature as “math()” func. But that one would be “hacky”.
This is the desired one
getJeunet as var(func: eq(name@fr, "Jean-Pierre Jeunet"))
And this example is using the “hacky” way
we get the uid from the var and transform it into a string. To use in uid_in func.
var(func: eq(name@fr, "Jean-Pierre Jeunet")){
IN as uid
a as string(IN)
}
I think we should have uid_in work with query variables. The fewer places we require UID literals, the better. At the very least, it should support the uid() function so you can say uid_in(director.film, uid(varName)).
I just learned last week from @pawan that shortest path queries’s from and to arguments support the uid() function.