fix(GraphQL): optimize eq filter queries (#7895)
Fixes GQLSAAS-1236.
This PR optimizes eq filter GraphQL queries.
For ex:
The below DQL query:
query {
queryPerson(filter: {nick: {eq: "Dgraph"}}){
id
name
nick
}
}
will now be written into:
query {
queryPerson(func: eq(Person.nick, "Dgraph")) @filter(type(Person)) {
Person.id : uid
Person.name : Person.name
Person.nick : Person.nick
}
}
which was earlier written into:-
query {
queryPerson(func: type(Person)) @filter(eq(Person.nick, "Dgraph")){
Person.id : uid
Person.name : Person.name
Person.nick : Person.nick
}
}
Problem
Solution
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
Coverage increased (+0.01%) to 37.113% when pulling f3395e3cc0b9f332cc1d21405183c91817fc922e on dshekhar95-cherry-pick-7895_new into c1be93b90a8b0dbd4c3e1302cb0b59dbdc3817df on main.
We should point out in the release notes that the optimization is not realized when complex filters (AND, NOT, OR) are present in the GraphQL query. For instance see the "Filter with nested 'and'" test in query_test.yaml
@dshekhar95 @matthewmcneely @MichelDiz - dgraph docs tells me that these are basic types https://dgraph.io/tour/basic/3/
The test cases test for eq for string, date time ... I am wondering if we should add cases for other types.
Another question here, how would this eq work for complex types like arrays / objects? Does this PR address those conditions?
The test cases test for
eqforstring,date time... I am wondering if we should add cases for other types.
As this PR strictly deals with adding @filter(type(XXX)) when it can, I don't think totally covering the other types is necessary.
Another question here, how would this
eqwork for complex types like arrays / objects? Does this PR address those conditions?
I don't think raw Objects are a valid type of argument for any comparison in GraphQL itself. Dgraph does have the in filter parameter which allows searching for values in array (really unordered sets) edges. There seems to be a test for that as it relates to this PR here