There can be only one input field named *

Issues GraphQL
, , ,
1

According to the docs:

The and is implicit for a single filter object. The above could be written equivalently as:

queryPost(filter: { 
    title: { allofterms: "GraphQL"},
    title: { allofterms: "Dgraph" } 
  } ) { ... }

I tried this and it causes the error:

"There can be only one input field named \"title\"."

Of course my field name was different but the main point is that the same field name was used twice without a separating conjunction.

Is this another bug? Or is the example in the docs wrong and this just needs to be notated as such.

Maybe a note needs to be added:

The and is implicit for a single filter object. Note: Each filter item may only be used once in each object scope.

2

You can use or, and and not filter to combine multiple filters.

query {
  queryPlayer (filter: { or: { title : { alloftext: "ABC"}}, title : { alloftext: "XYZ"} }) {
    id
  }
}

But this is a bug and doesn’t seem to work in all cases. The or, and and not filter must be an array instead of single value.

1 Like
3

If this is a bug, can you move this under Issues category, @arijit?

1 Like
4

What I would expect after working with and/or logic in the auth directive is for it to work almost the same way with arrays with the first and being understood.

I understand this would be a breaking change because there is no way to right GraphQL schema where a filter can be either an object or an array so filter: {title: {...}} would no longer work if this is implemented

These two queries would be equivalent:

# with understood `and`
query example1 {
  queryPost(filter: [
    {title: {allofterms: "GraphQL"}},
    {title: {allofterms: "Dgraph" }} 
  ] ) { ... }
}
# with defined `and` using an array:
query example1 {
  queryPost(filter: [{ 
    and: [
      {title: {allofterms: "GraphQL"}},
      {title: {allofterms: "Dgraph" }} 
    ]
  }] ) { ... }
}

Notice that filter would require an array instead of an object. This would be needed because { title: {...}, title: {...} } does not validate, but [{title: {...}}, {title: {...}}] does validate

This would also make nested and/or logic easier to understand:

# proposed usage of arrays:
query example1 {
  queryPost(filter: [
    {title: {allofterms: "Database"}},
    {or: [
      {title: {allofterms: "Dgraph" }}, 
      {and: [
        {title: {allofterms: "GraphQL±" }},
        {title: {allofterms: "GraphQL+-" }}
      ]}
    ]},
    {not: { title: {eq: "What is a Database?"} }}
  ] ) { ... }
}
# compared to current and *I think* equivalent:
query example1 {
  queryPost(filter: {
    title: {allofterms: "Database"},
    and: {
      title: {allofterms: "Dgraph" }}, 
      or: {
        title: {allofterms: "GraphQL±" },
        and: {
          title: {allofterms: "GraphQL+-" }
        }
      }
    },
    not: { title: {eq: "What is a Database?"} }
  } ) { ... }
}

Notice that and & or would be arrays while not is an object. However, not would be able to contain nested and/or parameters

1 Like
5

Yes. The behaviour would be similar to what we have for auth rules. We have noted this down in bug’s list and I will update you on the timeline after discussing with the team.

6

This would be breaking change to convert the filter type to Array. We will do it later in the future release if multiple users ask for it.

7

I understand. I am just thinking of the longevity of Dgraph. Fix it now early on when there are less users who it causes breaking change to, or do it later when it affects even more. This will be an endless battle with breaking changes to the graphql generated schema.

8

I am really excited about this coming with 20.11!

I did not realize that this could be accomplished without breaking changes with some current somewhat obscur and hidden spec features: GraphQL

If the value passed as an input to a list type is not a list and not the null value, then the result of input coercion is a list of size one, where the single item value is the result of input coercion for the list’s item type on the provided value

@arijit I believe that this will resolve this “bug” with an updated doc page changing some wording that indicate the list brackets are implicit for a single filter object for any and & or blocks. Feel free to close this as you see fit.

Nicely Done!!

9

Yes, this issue has been fixed and it will be part of the upcoming v20.11 release.

1 Like