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