graph,graphql,store: nested sorting

[kamilkisiela]

#3737

Given this schema:

type Country @entity {
  id: ID!
  capital: City!
  cities: [City!]!
}

type City @entity {
  id: ID!
  name: String
  population: Int
  landmarks: [String!]!
}

It adds fields of child entity to *_orderBy enum:

enum Country_orderBy {
   id
   capital
   cities
+  capital__id
+  capital__name
+  capital__population
}

• sort by type Child @entity { name: String }
• sort by type Child @entity { id: ID }
• can't sort by type Child @entity { names: [String] }
• can't sort by type Child @entity { secondLevelChild: AnotherEntity }
• can't sort by type Child @entity { secondLevelChildren: [AnotherEntity] }
• support @derivedFrom
• sort by interface Child { name: String }
• sort by interface Child { id: ID }
• sort interface by type Child @entity { name: String } (done in Nested Sorting: interface by non-derived child entity #4058)

[lutter]

I started reviewing this, but then realized that it also deals with sorting by interface fields, and now I am not certain how it relates to PR #4058. Should I continue reviewing this or is this superseded by that PR?

[kamilkisiela]

@lutter

I started reviewing this, but then realized that it also deals with sorting by interface fields, and now I am not certain how it relates to PR #4058. Should I continue reviewing this or is this superseded by that PR?

It deals with sorting by interface fields, #4058 adds sorting an interface by children (as it's a bit more complex).

[lutter]

I am still not completely through the PR, but figured these comments would be good to address to make some progress.

[kamilkisiela]

@lutter about the failing test, it works locally but I will try to use exact version on PostgreSQL docker image.

[kamilkisiela]

@lutter

Rows of musicians table are sorted by main_band, block_range columns. You can see that b1 is used by two musicians.

Sometimes the unit test is 🟢, but sometimes it's 🔴 .

Do you think that the order of row insertion affects the end result? These two rows are pretty much identical (block_range and main_band).

entity	data
Musician	{"id": "m2", "vid": 1, "name": "Lisa", "bands": ["b1"], "main_band": "b1", "block_range": "[0,)"}
Musician	{"id": "m1", "vid": 2, "name": "John", "bands": ["b1", "b2"], "main_band": "b1", "block_range": "[0,)"}
Musician	{"id": "m3", "vid": 3, "name": "Tom", "bands": ["b1", "b2"], "main_band": "b2", "block_range": "[1,)"}
Musician	{"id": "m4", "vid": 4, "name": "Valerie", "bands": [], "main_band": null, "block_range": "[1,)"}

After running the unit tests, I run the query generated by graph-node:

select 'Musician' as entity, to_jsonb(c.*) as data from (select  c.*
 from "sgd21"."musician" c left join "sgd21"."band" as cc on (cc."id" = c."main_band" and cc."block_range" @> 1)
where c.block_range @> 1
order by cc."id", cc.block_range
limit 100) c

I always get consistent results.

[lutter]

select 'Musician' as entity, to_jsonb(c.*) as data from (select  c.*
 from "sgd21"."musician" c left join "sgd21"."band" as cc on (cc."id" = c."main_band" and cc."block_range" @> 1)
where c.block_range @> 1
order by cc."id", cc.block_range
limit 100) c

I am not entirely sure what is going on here; for me locally, can_query_with_sorting_by_child_entity_id fails consistently. Is that the test you are talking about? If so, it should say order by cc.name, cc.id, cc.block_range based on the GraphQL for asc.

[lutter]

Nice work! Sorry it took so long to review.

One final thing: we should have an environment variable GRAPH_GRAPHQL_DISABLE_CHILD_SORTING which defaults to false that we can set to turn this off if it leads to performance issues. The flag should work just the same as GRAPH_GRAPHQL_DISABLE_BOOL_FILTERS does. I left comments where I think this needs to be checked to (a) suppress child sorting in the GraphQL schema and (b) return an error in queries.

Other than that, this should be good to go.

[dotansimha]

@lutter merged with the integration tests failing, it seems like the same on master. Unrelated to this PR, and the only change was a rebase.