## Description
After the GHC 9.4.5 upgrade the generated dc-api openapi spec was emitted with a different order. This change regenerates the version-controlled spec and types with the new order so that our CI check will pass. Other than order of fields these files are the same as before.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9446
Co-authored-by: Daniel Chambers <1214352+daniel-chambers@users.noreply.github.com>
GitOrigin-RevId: fbe00bef95e92cbe82b5213060826d096e98032d
## Description
This change adds support for querying into nested arrays in Data Connector agents that support such a concept (currently MongoDB).
### DC API changes
- New API type `ColumnType` which allows representing the type of a "column" as either a scalar type, an object reference or an array of `ColumnType`s. This recursive definition allows arbitrary nesting of arrays of types.
- The `type` fields in the API types `ColumnInfo` and `ColumnInsertSchema` now take a `ColumnType` instead of a `ScalarType`.
- To ensure backwards compatibility, a `ColumnType` representing a scalar serialises and deserialises to the same representation as `ScalarType`.
- In queries, the `Field` type now has a new constructor `NestedArrayField`. This contains a nested `Field` along with optional `limit`, `offset`, `where` and `order_by` arguments. (These optional arguments are not yet used by either HGE or the MongoDB agent.)
### MongoDB Haskell agent changes
- The `/schema` endpoint will now recognise arrays within the JSON validation schema and generate corresponding arrays in the DC schema.
- The `/query` endpoint will now handle `NestedArrayField`s within queries (although it does not yet handle `limit`, `offset`, `where` and `order_by`).
### HGE server changes
- The `Backend` type class adds a new type family `XNestedArrays b` to enable nested arrays on a per-backend basis (currently enabled only for the `DataConnector` backend.
- Within `RawColumnInfo` the column type is now represented by a new type `RawColumnType b` which mirrors the shape of the DC API `ColumnType`, but uses `XNestedObjects b` and `XNestedArrays b` type families to allow turning nested object and array supports on or off for a particular backend. In the `DataConnector` backend `API.CustomType` is converted into `RawColumnInfo 'DataConnector` while building the schema.
- In the next stage of schema building, the `RawColumnInfo` is converted into a `StructuredColumnInfo` which allows us to represent the three different types of columns: scalar, object and array. TODO: the `StructuredColumnInfo` looks very similar to the Logical Model types. The main difference is that it uses the `XNestedObjects` and `XNestedArrays` type families. We should be able to combine these two representations.
- The `StructuredColumnInfo` is then placed into a `FIColumn` `FieldInfo`. This involved some refactoring of `FieldInfo` as I had previously split out `FINestedObject` into a separate constructor. However it works out better to represent all "column" fields (i.e. scalar, object and array) using `FIColumn` as this make it easier to implement permission checking correctly. This is the reason the `StructuredColumnInfo` was needed.
- Next, the `FieldInfo` are used to generate `FieldParser`s. We add a new constructor to `AnnFieldG` for `AFNestedArray`. An `AFNestedArray` field parser can contain either a simple array selection or an array aggregate. Simple array `FieldParsers` are currently limited to subfield selection. We will add support for limit, offset, where and order_by in a future PR. We also don't yet generate array aggregate `FieldParsers.
- The new `AFNestedArray` field is handled by the `QueryPlan` module in the `DataConnector` backend. There we generate an `API.NestedArrayField` from the AFNestedArray. We also handle nested arrays when reshaping the response from the DC agent.
## Limitations
- Support for limit, offset, filter (where) and order_by is not yet fully implemented, although it should not be hard to add this
- Support for aggregations on nested arrays is not yet fully implemented
- Permissions involving nested arrays (and objects) not yet implemented
- This should be integrated with Logical Model types, but that will happen in a separate PR
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/9149
GitOrigin-RevId: 0e7b71a994fc1d2ca1ef73bfe7b96e95b5328531
## 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
>
## Description
->
This PR allows DC agents to define custom aggregate functions for their scalar types.
### Related Issues
->
GDC-189
### Solution and Design
>
We added a new property `aggregate_functions` to the scalar types capabilities. This allows the agent author to specify a set of aggregate functions supported by each scalar type, along with the function's result type.
During GraphQL schema generation, the custom aggregate functions are available via a new method `getCustomAggregateOperators` on the `Backend` type class.
Custom functions are merged with the builtin aggregate functions when building GraphQL schemas for table aggregate fields and for `order_by` operators on array relations.
### Steps to test and verify
>
• Codec tests for aggregate function capabilities have been added to the unit tests.
• Some custom aggregate operators have been added to the reference agent and are used in a new test in `api-tests`.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/6199
GitOrigin-RevId: e9c0d1617af93847c1493671fdbb794f573bde0c
## Description 🔖
This adds the ability to "customize & track" using the [new tracking ui](https://github.com/hasura/graphql-engine-mono/pull/5391).
A new button was added to implement this:
<img width="870" alt="Screen Shot 2022-09-16 at 12 37 14 PM" src="https://user-images.githubusercontent.com/49927862/190701948-1ad86717-f6be-4f67-8e0c-17b618790795.png">
## Solution and Design 🎨
This feature mostly makes use of components and hooks already created.
I was able to refactor some code to reduce code duplication and type duplication.
A few highlights on the refactor:
- `useTrackTable`, `useUntrackTable` and `useTrackSelectedTables` were all refactored into a single hook: `useTrackTable`. This hook has one main function but returns 4 wrapper functions: `trackTable`, `untrackTable`, `trackTables`, and `untrackTables`. This should make maintaining easier in the future.
- Synced up types between `MetadataTableConfig` and the customization form. Previously, the customization form had duplicated this same type, and there was some slight discrepancies between them.
- Modified `TableTrackingCustomizationModal` `onSubmit` return with a 2nd argument that's in the exact shape of `MetadataTableConfig` for convenience.
- Did some refactoring of the `DropDownMenu` component that should not interfere with anything. Exposed a few of the inner components for export and used these modular pieces in the current implementation. This ended up not being used in the feature, but left it in as it's a slight improvement.
I also added a function called `delayAsyncAction` [here](5e88262628/console/src/components/Common/utils/jsUtils.tsx (L416)) to create an artificial delay for `async` functions. This allows us to create a more confident UX when requests happen near-instantly. Introducing a tiny delay of around 300ms with good UI feedback (i.e. loading spinner) shows the user something is happening. I wanted to document this as I'm not sure it's something other will agree on. If it's against our UX philosophy, I can remove it, but I found it nice.
## Review Setup 💻
1. Run the code locally and go to `http://localhost:3000/data/v2/manage?database=YOUR_DATABASE_NAME_HERE`
2. You should see the new button as shown above to `Customize & Track`
3. Try it out with various field custom roots
4. Also try tracking and untracking tables both from the individual rows as well as the checkboxes as this logic was also modified in the refactor.
** I am not totally sure how much I need to put here for testing, I may want some help here from the team. **
## Review checklist. 📋
### Functionality
- [ ] Steps to verify console behaviour
### Tests
Going to open another PR for adding testing to the relevant areas. Will update this PR with a link once that's been done.
PR-URL: https://github.com/hasura/graphql-engine-mono/pull/5922
GitOrigin-RevId: e7c14be5b9bcc255a7b9ecfd43f1f84aa8aabba2
