This is a fundamental question that occurred to me by using dgraph for a while now.
Why do we need the “func” keyword when running queries? Is there anything else that could go into its place?
Consider the following query:
{
q(func: has(name)) {
uid
}
}
We now can change the query to various different functions (eq, le, uid, match, anyofterms, etc). However, to my knowledge the func: part never changes. Now, you could say that this a convention of the query language, however, I find this rather inconsistent when comparing it to filters:
I don’t know what the exact reason is, but it seems to me to be something related to the query parser. Maybe it’s better if func is explicit. There are other queries that use their own keywords like kshortest and there is an empty one that we use for aggregation. So, might be good to separate logically.
I believe if the query parser works the same way in parsing this part of the DQL syntax like the GraphQL syntax then this whole group of params gets converted into an object with their specific keys.
With this understanding, it may be possible to provide the same query with a different order or params:
{
n(first: 1, func: has(name)) { uid }
}
And without the func parameter name, it would be really hard to get the function and check that one and only one function was provided.
This is in line with how GraphQL syntax works. For example you cannot have an input without labeling that input. {getPost("0x2"){id}} is not valid, but {getPost(id:"0x2"){id}} is valid because the input is labeled.