Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support filter on expand #3904

Closed
campoy opened this issue Sep 3, 2019 · 6 comments · Fixed by #4404
Closed

Support filter on expand #3904

campoy opened this issue Sep 3, 2019 · 6 comments · Fixed by #4404
Assignees
Labels
area/querylang/filter Related to the filter directive. area/querylang Issues related to the query language specification and implementation. area/types Issues related to the type system. kind/feature Something completely new we should consider. priority/P3 Low priority, something to be done once everything else seems fixed. status/needs-specs Issues that require further specification before implementation.

Comments

@campoy
Copy link
Contributor

campoy commented Sep 3, 2019

It would be very useful to filter what fields are included in an expand operation.

For instance, we could expand only the predicates pointing to values of type Person from a Movie as such:

{
    q(func: type(Movie)) {
        expand(_all_) @filter(type(Person)) {
            first_name
        }
    }
}

This would expand the predicates of type uid or [uid] and show only the nodes associated to the type Person.

@campoy campoy added area/querylang Issues related to the query language specification and implementation. area/types Issues related to the type system. kind/feature Something completely new we should consider. status/accepted We accept to investigate/work on it. labels Sep 3, 2019
@campoy campoy added this to the Dgraph v1.2 milestone Sep 3, 2019
@gitlw
Copy link

gitlw commented Sep 3, 2019

@campoy It seems the syntax expand(type(Person)) is more concise and intuitive. What do you think?

@campoy
Copy link
Contributor Author

campoy commented Sep 11, 2019

expand(type(Person)) and expand(Person) @filter(type(Person)) are different things, and they're both valid.

Given a type Person as follows:

type Person {
  name: string
  age: int
  best_friend: uid   // points to a Person
  lives_with: [uid]  // holds an array of objects: some of type Person, some of type Pet
  pets: [uid]        // holds an array of objects of type Pet
}

expand(Person)

expand(Person) is replaced by the predicates defined in the Person type.

{
  q(func: eq(name, "Francesc")) {
    expand(Person)
  }
}

Is the same as writing

{
  q(func: eq(name, "Francesc")) {
    name
    age
    best_friend
    lives_with
    pets
  }
}

You can read more on expand(Person) on issue #3903.

expand(X) @filter(type(Person))

This will expand whatever is requested in the expand function, either _all_ or Person. But then only the values of type Person will be kept.

So given a value of Person

{
  "uid": "0x1234",
  "dgraph.type": "Person",
  "name": "Frodo",
  "age": 25,
  "best_friend": {
     "uid": "0x2345",
     "dgraph.type": "Person",
     "name": "Sam",
     "age": 24
  },
  "lives_with": [
      {
        "uid": "0x2345",
        "dgraph.type": "Person",
        "name": "Sam",
        "age": 24       
      },
      {
        "uid": "0x3456",
        "dgraph.type": "Pet",
        "name": "Milou"
      }
  ],
  "pets": [
      {
        "uid": "0x3456",
        "dgraph.type": "Pet",
        "name": "Milou"
      }
  ]
}

The following query:

{
  q(func: eq(name, "Frodo")) {
    expand(_all_) @filter(type(Person)) {
       expand(Person)
    }
  }
}

would:

  • expand all the fields in the types associated to "Frodo", in this case just those of "Person"
  • filter the predicates to only those of type "Person", therefore dropping name, age, pets, and some of the values in lives_with
  • expand all of the predicates in Person for each one of the nodes in pointed by the predicates expanded before

The result would be the following:

{
  "best_friend": {
     "name": "Sam",
     "age": 24
  },
  "lives_with": [
      {
        "name": "Sam",
        "age": 24       
      }
  ]
}

I wonder if this is clear enough. I think I need to spend some time writing more specs for these changes.
For now let's keep them blocked.

@campoy campoy added status/needs-specs Issues that require further specification before implementation. area/querylang/filter Related to the filter directive. priority/P3 Low priority, something to be done once everything else seems fixed. and removed status/accepted We accept to investigate/work on it. labels Sep 11, 2019
@campoy campoy modified the milestones: Dgraph v1.2, Unplanned (v1.x) Sep 13, 2019
@campoy
Copy link
Contributor Author

campoy commented Sep 17, 2019

Hey @martinmr , could you have a look at this issue?
I think you might be the best person to handle this right now.

@martinmr
Copy link
Contributor

I have a PR for this already but there is a weird bug that I haven't had the chance to debug yet.

@Necmttn
Copy link

Necmttn commented Nov 14, 2019

Hey, @martinmr is there any status update about this issue?

@campoy
Copy link
Contributor Author

campoy commented Dec 11, 2019

This issue is related to #4399, as expand(_all_) might expand value predicates and filters should apply on them too (or not, to be decided in that issue).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/querylang/filter Related to the filter directive. area/querylang Issues related to the query language specification and implementation. area/types Issues related to the type system. kind/feature Something completely new we should consider. priority/P3 Low priority, something to be done once everything else seems fixed. status/needs-specs Issues that require further specification before implementation.
Development

Successfully merging a pull request may close this issue.

4 participants