346804fc67
## Description This change adds support for nested object fields in HGE IR and Schema Cache, the Data Connectors backend and API, and the MongoDB agent. ### Data Connector API changes - The `/schema` endpoint response now includes an optional set of GraphQL type definitions. Table column types can refer to these definitions by name. - Queries can now include a new field type `object` which contains a column name and a nested query. This allows querying into a nested object within a field. ### MongoDB agent changes - Add support for querying into nested documents using the new `object` field type. ### HGE changes - The `Backend` type class has a new type family `XNestedObjects b` which controls whether or not a backend supports querying into nested objects. This is currently enabled only for the `DataConnector` backend. - For backends that support nested objects, the `FieldInfo` type gets a new constructor `FINestedObject`, and the `AnnFieldG` type gets a new constructor `AFNestedObject`. - If the DC `/schema` endpoint returns any custom GraphQL type definitions they are stored in the `TableInfo` for each table in the source. - During schema cache building, the function `addNonColumnFields` will check whether any column types match custom GraphQL object types stored in the `TableInfo`. If so, they are converted into `FINestedObject` instead of `FIColumn` in the `FieldInfoMap`. - When building the `FieldParser`s from `FieldInfo` (function `fieldSelection`) any `FINestedObject` fields are converted into nested object parsers returning `AFNestedObject`. - The `DataConnector` query planner converts `AFNestedObject` fields into `object` field types in the query sent to the agent. ## Limitations ### HGE not yet implemented: - Support for nested arrays - Support for nested objects/arrays in mutations - Support for nested objects/arrays in order-by - Support for filters (`where`) in nested objects/arrays - Support for adding custom GraphQL types via track table metadata API - Support for interface and union types - Tests for nested objects ### Mongo agent not yet implemented: - Generate nested object types from validation schema - Support for aggregates - Support for order-by - Configure agent port - Build agent in CI - Agent tests for nested objects and MongoDB agent PR-URL: https://github.com/hasura/graphql-engine-mono/pull/7844 GitOrigin-RevId: aec9ec1e4216293286a68f9b1af6f3f5317db423 |
||
---|---|---|
.. | ||
src | ||
.gitignore | ||
.nvmrc | ||
Dockerfile | ||
package-lock.json | ||
package.json | ||
README.md | ||
tsconfig.json |
Data Connector Agent Reference Implementation
This directory contains a barebones implementation of the Data Connector agent specification which fetches its data from static JSON files. It can be used as a reference implementation for testing, and as a reference for developers working on backend services.
Requirements
- NodeJS 16
Build & Run
> npm install
> npm start
Docker Build & Run
> docker build . -t dc-reference-agent:latest
> docker run -it --rm -p 8100:8100 dc-reference-agent:latest
Dataset
The dataset exposed by the reference agent is sourced from https://github.com/lerocha/chinook-database/
More specifically, the Chinook.xml.gz
file is a GZipped version of https://raw.githubusercontent.com/lerocha/chinook-database/ce27c48d9f375f81b7b68bacdfddf3c4458acc49/ChinookDatabase/DataSources/_Xml/ChinookData.xml
The schema-tables.json
is manually derived from the schema of the data as can be seen from the CREATE TABLE
etc DML statements in the various per-database-vendor SQL scripts that can be found in /ChinookDatabase/DataSources
in that repo.
The datasets can be operated on via the /datasets
resources as described in dc-agents/README.md
.
Configuration
The reference agent supports some configuration properties that can be set via the value
property of configuration
on a source in Hasura metadata. The configuration is passed to the agent on each request via the X-Hasura-DataConnector-Config
header.
The configuration that the reference agent can take supports two properties:
tables
: This is a list of table names that should be exposed by the agent. If omitted all Chinook dataset tables are exposed. If specified, it filters all available table names by the specified list.schema
: If specified, this places all the tables within a schema of the specified name. For example, ifschema
is set tomy_schema
, all table names will be namespaced undermy_schema
, for example["my_schema","Album"]
. If not specified, then tables are not namespaced, for example["Album"]
.
Here's an example configuration that only exposes the Artist and Album tables, and namespaces them under my_schema
:
{
"tables": ["Artist", "Album"],
"schema": "my_schema"
}
Here's an example configuration that exposes all tables, un-namespaced:
{}