4f5e10c636
<!-- The PR description should answer 2 important questions: --> ### What This PR adds two new operand types for `BooleanExpressionType` in OpenDD: `objectAggregate` and `scalarAggregate`. These two operand types are then validated in metadata resolve to ensure their correctness. Their design is based on [this RFC](https://github.com/hasura/v3-engine/pull/945#issuecomment-2325652794). They are hidden from the OpenDD JSON Schema and their usage is blocked by default via a new unstable feature flag. They are also currently not "usable", as the metadata resolve code that would use an `objectAggregate` operand-ed `BooleanExpressionType` to satisfy an aggregate predicate over an array relationship does not exist. This will be added in a future PR; this PR is big enough! ### How A new unstable feature `enable_aggregation_predicates` has been added to gate this feature behind while it is in development. The new OpenDD types have been added to `crates/open-dds/src/boolean_expression.rs`. A new metadata resolve stage `aggregate_boolean_expressions` has been added that specifically resolves these two new operand types. Most of the new code changes in this PR exist in this new stage. The output of this stage is composed into the `boolean_expressions` stage afterwards, but other than just being consumed and included there, it is unused for now. In a future PR it will be used when resolving object-operanded `BooleanExpressionTypes`. An exhaustive set of metadata resolve tests has been added to test all the error, warning and passing cases for both object and scalar aggregate operands (`crates/metadata-resolve/tests/failing/aggregate_boolean_expressions/` and `crates/metadata-resolve/tests/passing/aggregate_boolean_expressions/`). These files make up the vast majority of the file count in this PR. V3_GIT_ORIGIN_REV_ID: e0e030b322d05212a0e2630acc9f4db7b05000c1 |
||
|---|---|---|
| .. | ||
| .cargo | ||
| crates | ||
| docs | ||
| nix | ||
| rfcs | ||
| static | ||
| .dockerignore | ||
| .envrc | ||
| .envrc.local.example | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc | ||
| Cargo.lock | ||
| Cargo.toml | ||
| changelog.md | ||
| ci.docker-compose.yaml | ||
| CONTRIBUTING.md | ||
| custom-connector.Dockerfile | ||
| dev-auth-webhook.Dockerfile | ||
| docker-compose.yaml | ||
| Dockerfile | ||
| flake.lock | ||
| flake.nix | ||
| justfile | ||
| README.md | ||
| rust-toolchain.toml | ||
Hasura GraphQL Engine V3
Hasura V3 is the API execution engine, based over the Open Data Domain Specification (OpenDD spec) and Native Data Connector Specifications (NDC spec), which powers the Hasura Data Delivery Network (DDN). The v3-engine expects to run against an OpenDDS metadata file and exposes a GraphQL endpoint according to the specified metadata. The v3-engine needs a data connector to run alongside, for the execution of data source specific queries.
Data connectors
Hasura v3-engine does not execute queries directly - instead it sends IR (abstracted, intermediate query) to NDC agents (aka data connectors). To run queries on a database, we'll need to run the data connector that supports the database.
Available data connectors are listed at the Connector Hub
For local development, we use the reference agent implementation that is a part of the NDC spec.
To start the reference agent only, you can do:
docker compose up reference_agent
Run v3-engine (with Postgres)
Building with Docker
You can also start v3-engine, along with a Postgres data connector and Jaeger for tracing using Docker:
docker compose up
Open http://localhost:3000 for GraphiQL, or http://localhost:4002 to view traces in Jaeger.
Note: you'll need to add {"x-hasura-role": "admin"} to the Headers section to
run queries from GraphiQL.
NDC Postgres is the official connector
by Hasura for Postgres Database. For running V3 engine for GraphQL API on
Postgres, you need to run NDC Postgres Connector and have a metadata.json file
that is authored specifically for your Postgres database and models (tables,
views, functions).
The recommended way to author metadata.json for Postgres, is via Hasura DDN.
Follow the Hasura DDN Guide to create a Hasura DDN project, connect your cloud or local Postgres Database (Hasura DDN provides a secure tunnel mechanism to connect your local database easily), and model your GraphQL API. You can then download the authored metadata.json and use the following steps to run GraphQL API on your local Hasura V3 engine.
Running tests
To run the test suite, you need to docker login to ghcr.io first:
docker login -u <username> -p <token> ghcr.io
where username is your github username, and token is your github PAT. The
PAT needs to have the read:packages scope and Hasura SSO configured. See
this
for more details.
Running just watch will start the Docker dependencies, build the engine, and
run all the tests.
Alternatively, run the tests once with just test
Updating goldenfiles
There are some tests where we compare the output of the test against an expected golden file. If you make some changes which expectedly change the goldenfile, you can regenerate them like this:
just update-golden-files
Some other tests use insta, and these can be reviewed with
cargo insta review. If the cargo insta command cannot be found, install it
with cargo install cargo-insta.
Run benchmarks
The benchmarks operate against the reference agent using the same test cases as the test suite, and need a similar setup.
To run benchmarks for the lexer, parser and validation:
cargo bench -p lang-graphql "lexer"
cargo bench -p lang-graphql "parser"
cargo bench -p lang-graphql "validation/.*"