mirror of
https://github.com/hasura/graphql-engine.git
synced 2024-12-16 09:51:59 +03:00
0624a7553d
## Description This PR implements the GraphQL schema and execution for aggregate relationships. In the `schema` crate, the new `model_aggregate_relationship_field` function handles generating schema for ModelAggregateTarget relationships. It mostly delegates the meat of its implementation to reused logic; some refactoring has occurred to make this possible. This involved changes in `select_many`, `select_aggregate` and `model_arguments`. The creation of the model arguments field argument now exists in `model_arguments` and is reused by `select_many` and `select_aggregate`. The creation of all aggregate field arguments is now in `select_aggregate::generate_select_aggregate_arguments`, and is then reused when generating the aggregate relationship field. That field is annotated with the new `RelationshipToModelAggregate` annotation. In the `execute` crate, the logic around generating an the aggregate selection IR was moved from `select_aggregate` into `model_selection`. This was so it can be reused by the logic in `relationship` that now uses it to generate an aggregate selection when encountering an `RelationshipToModelAggregate` field. Inside `relationship` some rearranging was done so that `build_local_model_relationship` and `build_remote_relationship` could work with either a normal model selection IR or the new aggregate selection IR. The necessitated moving the creation of that IR outside those functions into the caller, so the different callers can create different IR (normal vs aggregate IR). This also reduced code duplication. New tests have been added to `engine` that cover aggregate relationships and also remote joined aggregate relationships. This PR also corrects two bugs in metadata resolve revealed by new testing: * The filter input field name in `GraphqlConfig` must be specified if using an aggregate relationship * The filter input type name defined on a `Model` must be specified if that model is the target of an aggregate relationship. Conversely, the filter input type name can be specified if the `Model` itself doesn't define an aggregate, but is still involved in a aggregate relationship (this previously produced an error). This PR completes the feature, but it is still hidden behind the experimental flag. There will be a follow up PR to remove that and expose the functionality by default. JIRA: [V3ENGINE-160](https://hasurahq.atlassian.net/browse/V3ENGINE-160) [V3ENGINE-160]: https://hasurahq.atlassian.net/browse/V3ENGINE-160?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ V3_GIT_ORIGIN_REV_ID: d499371906f7af71a4017c7c3ae75b7693cd3fa7 |
||
|---|---|---|
| .. | ||
| aggregate_expression_in_relationship | ||
| aggregate_expressions | ||
| boolean_expression | ||
| command_no_ndc_function | ||
| simple | ||
| subgraph_invalid_name | ||
| supergraph_too_many_graphql_configs | ||