Filtering on the basis of child entities

[azf20]

Subgraph consumers can currently only filter and sort on the basis of top-level entity fields. As a consumer, I want to be able to filter and sort on the basis of child entity fields.

Schema:

type Author @entity {
  id: ID!
  genre: Genre
  userProfile: User @derived(field: "id")
}

type User @entity {
  id: ID!
  dateOfBirth: String
  country: String
}

Query:

query {
  authors(where: {userProfile: { dateOfBirth_eq: "1987-04-03" } }) {
    id
  }
}

• Will there need to be a limit on how many layers deep a filter can be applied? Restrict at one level, at least to begin with
• Are there any considerations around arrays of child entities, vs. single child entities?
• How will this work with interfaces?
• Will there be a conflict between userProfile: "12345" and the nested filter? Will need to be a union of a String and an object, or make a breaking change

Meta-task: compare with syntax from other projects

[Jannis]

From https://www.apollographql.com/docs/apollo-server/schema/unions-interfaces/#union-type:

All of a union's included types must be object types (not scalars, input types, etc.). Included types do not need to share any fields.

So that means we can't support both

where: { userProfile: "foo" }

and

where: { userProfile: { id: "foo" } }

at the same time. 😢

[dotansimha]

All of a union's included types must be object types (not scalars, input types, etc.). Included types do not need to share any fields

Yeah, because union and interfaces need to be resolved using resolveType or isTypeOf, while scalars / input types doesn't have the ability to do that, so we can't do UserFilter | String.

So ideally, we can introduce a new form of generating field arguments, that is more flexible and takes child entities into consideration, and gradually deprecate the existing one?
We can also experiment with @oneOf implementation (graphql/graphql-spec#825) to validate the input types.

[kamilkisiela]

Will there need to be a limit on how many layers deep a filter can be applied? Restrict at one level, at least to begin with

I guess it depends on how the data is fetched. All these filters could be applied as one or as many depending on the data fetching implementation. If some of them are super heavy for the database, we could define a score for them and calculate the complexity/heaviness of the query (score of 1200, where the limit is 250 will block the query from running).

Are there any considerations around arrays of child entities, vs. single child entities?

I'm not sure what do you mean here.

How will this work with interfaces?

All the arguments defined within an interface has to be defined in types implementing this interface, no extra arguments in these types. https://stackblitz.com/edit/typescript-mjzhzw

Will there be a conflict between userProfile: "12345" and the nested filter? Will need to be a union of a String and an object, or make a breaking change

Exactly what Dotan and Jannis said.

[Jannis]

How will this work with interfaces?

All the arguments defined within an interface has to be defined in types implementing this interface, no extra arguments in these types. https://stackblitz.com/edit/typescript-mjzhzw

What @azf20 meant was that for any interface defined in the subgraph's GraphQL schema, the generated GraphQL API will have fields such as bicycle(id: "...") and bicycles(where: { ... }, ...). Queries against these interfaces will query across all concrete types implementing the interface. So the question was how we'd generate child filters when interfaces are involved.

I think the answer is fairly straight-forward: we should only generate child filter arguments for the fields in the interface, not in the concrete types that implement it.

[azf20]

Are there any considerations around arrays of child entities, vs. single child entities?

Given:

author @entity {
  id: ID!
  name: String!
  books: [Book]
}

If I query for:

authors(where: books { genre_eq: "Horror" } ) {
  id
  name
  books { 
    id
  }
}

Presumably I get authors where any of their books have the Horror genre. Though is there a use case for selecting only horror (this might be a broader question about filtering on the basis of arrays). But also highlighting that the implementation of this filtering would presumably be different.

[azf20]

As discussed yesterday:

• We will not break the generated API at this time, so we can't use fieldName to filter child entities
• I propose fieldName_, i.e.

authors(where: books_: { genre: "Horror" } ) {
  id
}

Though this might be a bit opaque / not "graphQL-y", so open to suggestions. Other ideas:

• books_child
• books_entity

I think this does highlight the need to (at some point) release a v2 with breaking changes.

cc @lutter @Jannis @dotansimha @kamilkisiela

[dotansimha]

As discussed yesterday:

• We will not break the generated API at this time, so we can't use fieldName to filter child entities
• I propose fieldName_, i.e.

authors(where: books_: { genre: "Horror" } ) {
  id
}

Though this might be a bit opaque / not "graphQL-y", so open to suggestions. Other ideas:

• books_child
• books_entity

Sounds good, we can start with that and see how it looks like. Other suggestions are totally valid as well.

I think this does highlight the need to (at some point) release a v2 with breaking changes.

Makes a lot of sense, it's a good thing that we tackle some of these now, it will be easier to plan v2 of the GraphQL API.

[leoyvens]

We could start with supporting only the form books_genre: "Horror"

[azf20]

We could start with supporting only the form books_genre: "Horror"

That is interesting, though won't that lead to quite explosive Filter types?

[leoyvens]

That's a good point. Ok, I guess I don't mind the trailing _.

[elhaix]

I hope I am getting the gist of this issue, if so, it also depends in how your data is structured.

In this query, I am applying a filter to a child entity. Again, it depends if your data model supports this. The Graph also offers you the ability to create your own graphs where I'm sure you could massage the model to your liking:

# get a list of token pools for "WETH"
# WETH/USDT poolID (500 feeTier): 0x11b815efb8f581194ae79006d24e0d814b7697f6
{
tokens(where:{symbol:"WETH"}) {
    name
    symbolID: id
    whitelistPools(where: {feeTier: "500"}) {   # child entity filter
      poolID: id
      feeTier
      liquidity
      token0Price
      token1Price
      token0 {
        id
        symbol
        name	
        volumeUSD
        decimals
      }
      token1 {
        id
        symbol
        name
        volumeUSD
        decimals
      }
    }
  }
}

[mihoward21]

Super excited for this update! Thank you all for working on this feature. Do you all know when this will be live for us to use? And does this update include sorting as well, or just filtering?

[azf20]

Hi @mihoward21 this is currently in testing, will ping this thread! The initial feature is just filtering, with sorting to come (follow #3737 for more!)