Allow to filter queries by child entity

[kamilkisiela]

#2960

Given the schema:

type Purpose @entity {
  id: ID!
  sender: Sender!
  purpose: String!
  createdAt: BigInt!
  transactionHash: String!
}

type Sender @entity {
  id: ID!
  address: Bytes!
  purposes: [Purpose!] @derivedFrom(field: "sender")
  createdAt: BigInt!
  purposeCount: BigInt!
}

The sender_ is added to Purpose_filter input object.

input Purpose_filter {
    ...
+  sender_: Sender_filter
}

The Sender_filter input object is untouched.

Example

query {
  purposes(
    where: {
      purpose_contains: "...",
      sender_: {
        id: "..."
      }
    }
  ) {
    id
    sender {
      id
      purposeCount
    }
  }
}

select
  'Purpose' as entity,
  to_jsonb(c.*) as data
from
  (
    select
      c.*
    from
      "sgd1"."purpose" c
    where
      c.block_range @ > $ 1
      and c."purpose" like $ 2
      and (
        exists (
          select
            1
          from
            "sgd1"."sender" as i
          where
            c."sender" = i."id"
            and i."block_range" @ > $ 3
            and i."id" = $ 4
        )
      )
    group by
      c.id
    order by
      c."id"
    limit
      100
  ) c

Child filters are limited to be only 1 level deep, so no Child(Child(...)) and this pull request DOES NOT implement a support for interface types.

Continues #3022

[lutter]

Could you rebase this to latest master when you get a chance?

[dotansimha]

@lutter done! :)

Note that this PR is only for filtering, for sorting we have this one: #3096 (targeted into this PR, not master, and @kamilkisiela had some questions there before proceeding).

[lutter]

Getting closer! I actually hadn't thought about the issue that forced you to use group by but I think using the exists(select 1 ..) strategy I outlined in the comment will make this easier.

We'll also need tests for all this; the best place for them is probably graphql/tests/query.rs - I recently revamped them to (hopefully) make it easier to add tests there. The tests for this should use child filters that traverse Musician.bands, Musician.written_songs, Band.members, Song.written_by and SongStat.song. For example, what I have in mind for Musician.bands is something like musicians(where: { bands_: { name: "something" } }) { id }

[lutter]

This is getting really, really close. There's a few smallish things to touch up, but other than that, this is almost ready.

[lutter]

This would be better as an enum AttributeStorage { Direct, Derived }; even clearer would be to make EntityFilter::Child a struct, i.e.

    Child {
        attr: Attribute,
        entity_type: EntityType,
        filter: Box<EntityFilter>,
        derived: bool,
    },

[kamilkisiela]

845b35e

[lutter]

This, from line 401, would be clearer and avoid an unwrap() like this:

        let input_field_type = match input_field_type {
            None => {
                let mut input_values: Vec<InputValue> = vec![];

                if let Some(parent) = parent_type_name {
                    extend_with_child_filter_input_value(field, &parent, &mut input_values);
                }

                return Some(input_values);
            }
            Some(input_field_type) => input_field_type,
        };

[lutter]

Or, even better to do what follows in the match, too and avoid the early return:

        let mut input_values: Vec<InputValue> = match input_field_type {
            None => {
                vec![]
            }
            Some(input_field_type) => vec![
                "",
                "not",
                "contains",
                "contains_nocase",
                "not_contains",
                "not_contains_nocase",
            ]
            .into_iter()
            .map(|filter_type| {
                input_value(
                    &field.name,
                    filter_type,
                    Type::ListType(Box::new(Type::NonNullType(Box::new(
                        input_field_type.clone(),
                    )))),
                )
            })
            .collect(),
        };

        if let Some(parent) = parent_type_name {
            extend_with_child_filter_input_value(field, &parent, &mut input_values);
        }

        Some(input_values)

This could also be a let mut input_values = input_field_type.map(|input_field_type| ...).unwrap_or(vec![]) but I am fine with either

[kamilkisiela]

1baae95

[lutter]

This is get_base_type from graph/src/data/graphql (just do something like use graph::data::graphql::TypeExt as _ to be able to use it)

[kamilkisiela]

866883c

[lutter]

How about something like Child filters can not be nested?

[kamilkisiela]

f00526f

[lutter]

Very minor but these two push_sql could be collapsed into one

[kamilkisiela]

a7c70e4

[lutter]

Shouldn't that be c.id = any(i.{parent_field}) ? And similar in the comments for the other cases

[kamilkisiela]

7305f53

[lutter]

This needs to use BlockRangeColumn::contains - the way it is written now only works for mutable entities, but would fail for immutable ones since they don't have a block_range column, only a block$ column

[kamilkisiela]

f6721a3

[lutter]

This is good to go - there's one small thing around how the commits are structured/named: see this for how we usually do that. With this PR, it might be best to just squash everything into a mega commit all: Add child filters

[LukvonStrom]

@ALL (@lutter, @kamilkisiela) when is the ETA for merge of this awesome addition to the graphprotocol? :)

[kamilkisiela]

@lutter I squashed all commits and renamed it

[mhpaler]

@kamilkisiela @lutter and anyone else involved in this PR. Kinda late to the party on this one, but I'd like to offer a HUGE thank you for getting this into the graph-node. It's just such an amazing boost to querying. Thank you!!