There can be only one input field named *

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