Filter is ignored on value predicates

[campoy]

What version of Dgraph are you using?

master

Have you tried reproducing the issue with the latest release?

yes

What is the hardware spec (RAM, OS)?

n/a

Steps to reproduce the issue (command/config used to run Dgraph).

Create a new dataset with the following schema:

<name>: [string] @index(exact) .

and send the following mutation to have some data

{
  set {
    _:a <name> "One" .
    _:a <name> "Two" .
  }
}

Expected behaviour and actual result.

When you run the following query, you'll fetch both values:

{
  q(func: has(name)) {
    name
  }
}

result:

{
  "data": {
    "q": [
      {
        "name": [
          "One",
          "Two"
        ]
      }
    ]
  }
}

If I filter by value, I should be able to get only the one with value "One".

{
  q(func: has(name)) {
    name @filter(eq(name, "One"))
  }
}

Unfortunately, this will return both values.

What to do?

We should either fix this issue, or make it clear these filters are not supported.

I argue we should support them, as we already do for filters facets for value predicates (#4034)

[MichelDiz]

This is feasible but would make at first the syntax confusing for new users. It is one thing to apply functions to Edges or value facets. Another thing is to apply functions to list values (list type).

Imagine how confusing. You have filters in predicates and filters in outgoing edges. How to visually differentiate them? if you are new to GraphQL + -.

{
  q (func: has (name)) {
    name @filter(eq (name, "One"))
    something @filter(eq (title, "Big Bang"))
    something2 @filter(has (friend))
  }
}

I believe that visually filters help separate what is value/pred from outgoing edges/object. As it stands above it also gets crowded visually.

Filters are already applicable in the list via Root query func. In facets is understandable, but not so much list values in the body of the query. This can also add complexity to the GraphQL layer. Or just be a feature without much use.

Another example, by the same logic there should be pagination in List Type values (first: 1, offset: 2). But as it says in the documentation, list values ​​are non-deterministic. So it would make no sense for this function.

I wouldn't be against it, but it seems visually bad for GraphQL+- syntax and I don't know if it seems useful. Users can handle this via the business logic application. Need more thought.

Cheers.

[manishrjain]

Seems to be doing the right thing. name has two values, "One" and "Two", so the filter is finding the "One" there and returning the edge, which has both the values. Probably, our docs can be made to explain that better.