dgraph icon indicating copy to clipboard operation
dgraph copied to clipboard

fix(GraphQL): optimize eq filter queries (#7895)

Open dshekhar95 opened this issue 3 years ago • 3 comments

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

dshekhar95 avatar Sep 16 '22 16:09 dshekhar95

CLA assistant check
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.

CLAassistant avatar Sep 16 '22 16:09 CLAassistant

Coverage Status

Coverage increased (+0.01%) to 37.113% when pulling f3395e3cc0b9f332cc1d21405183c91817fc922e on dshekhar95-cherry-pick-7895_new into c1be93b90a8b0dbd4c3e1302cb0b59dbdc3817df on main.

coveralls avatar Sep 16 '22 17:09 coveralls

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

matthewmcneely avatar Sep 19 '22 18:09 matthewmcneely

@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?

skrdgraph avatar Sep 27 '22 10:09 skrdgraph

The test cases test for eq for string, 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.

matthewmcneely avatar Sep 28 '22 17:09 matthewmcneely

Another question here, how would this eq work 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

matthewmcneely avatar Sep 28 '22 17:09 matthewmcneely