graphql-engine/v3/changelog.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

269 lines
6.9 KiB
Markdown
Raw Normal View History

# Changelog
## [Unreleased]
### Added
### Fixed
### Changed
## [v2024.07.25]
### Fixed
- Ensured `traceresponse` header is returned
## [v2024.07.24]
### Added
- The metadata resolve step now emits warnings to let users know about
soon-to-be deprecated features and suggest fixes.
### Fixed
- Fixes a bug where boolean expressions passed as arguments would not be
translated into NDC `Expression` types before being sent to the data
connector.
- Fixes a bug where relationships within nested columns would throw an internal
error. While generating NDC relationship definitions, engine would ignore
columns with nested selection.
- Renamed the `ArgumentPreset` for data connectors to
`DataConnectorArgumentPreset` to avoid ambiguity in generated JSONSchema.
### Changed
- Fixed a bug where command targeted relationships were not using the Open DD
argument name instead of the data connector's argument name when querying the
data connector
## [v2024.07.18]
### Added
Implement remote relationship predicates in where filter clause (#761) Now, users can filter their queries using remote relationships in the filter predicate. Users need to provide the relationships for comparison in `comparableRelationships` field of the newer `BooleanExpressionType` opendd metadata. Minimal Algorithm: ``` Relationship: ARemoteB => Model_A -> Model_B (remote NDC) Column Mapping: (A_column_1, B_column_1), (A_column_2, B_column_2). query: Model_A: where: ARemoteB: {B_column_3: {_eq: value}} Step 1: Fetch RHS column values (in mapping) from remote target model SELECT B_column_1, B_column_2 from model_b_collection WHERE B_column_3 = value; yields the following rows [ [(B_column_1, b_value_1), (B_column_2, b_value_2)], [(B_column_1, b_value_11), (B_column_2, b_value_22)], ] Step 2: Using above rows the generate LHS column filter for Model_A query. SELECT <fields> from model_a_collection WHERE ((A_column_1 = b_value_1) AND (A_column_2 = b_value_2)) OR ((A_column_1 = b_value_11) AND (A_column_2 = b_value_22)) The above comparison is equivalent to WHERE (A_column_1, A_column_2) IN ((b_value_1, b_value_11), (b_value_2, b_value_22)) ``` Sample query: ```graphql query MyQuery { Track( where: { _or: [ { AlbumRemote: { Artist: { ArtistId: { _eq: 2 } } } } { TrackId: { _eq: 3 } } ] } ) { TrackId AlbumRemote { Artist { ArtistId Name } } } } ``` In the query above, `AlbumRemote` is a remote relationship which targets a model backed by a different data connector. V3_GIT_ORIGIN_REV_ID: 7aa76fcae83e1f22de460f1eef5648fb7a35c047
2024-07-18 10:46:16 +03:00
#### Remote Relationships in Query Filter
We have enhanced the GraphQL query capabilities to support array and object
relationships targeting models backed by different data connectors. This allows
you to specify remote relationships directly within the `where` expression of
your queries.
**Example:** Retrieve a list of customers who have been impacted by cancelled
orders during the current sale event. This data should be filtered based on
order logs stored in a separate data source.
```graphql
query CustomersWithFailedOrders {
Customers(
where: {
OrderLogs: {
_and: [
{ timestamp: { _gt: "2024-10-10" } }
{ status: { _eq: "cancelled" } }
]
}
}
) {
CustomerId
EmailId
OrderLogs {
OrderId
}
}
}
```
By incorporating remote relationships into the where expression, you can
seamlessly query and filter data that spans across multiple data sources, making
your GraphQL queries more versatile and powerful.
### Fixed
- Build-time check to ensure boolean expressions cannot be built over nested
array fields until these are supported.
- Fixed a bug where command targeted relationships were not using the OpenDD
argument name instead of the data connector's argument name when querying the
data connector.
## [v2024.07.10]
### Fixed
- Fixes a bug with variable nullability coercion. Specifically, providing a
non-null variable for a nullable field should work, as all non-nullable
variables can be used as nullable variables via "coercion".
- Fixes a bug where data connectors without the `foreach` capability were not
allowed to create local relationships
## [v2024.07.04]
### Added
- Query Usage Analytics - usage analytics JSON data is attached to `execute`
span using `internal.query_usage_analytics` attribute
Enable `BooleanExpressionType`s (#783) <!-- The PR description should answer 2 (maybe 3) important questions: --> ### What # BooleanExpressionType A new metadata kind `BooleanExpressionType` can now be defined. These can be used in place of `ObjectBooleanExpressionType` and `DataConnectorScalarRepresentation`, and allow more granular control of comparison operators and how they are used. The old metadata types still work, but will eventually be deprecated. ```yaml kind: BooleanExpressionType version: v1 definition: name: album_bool_exp operand: object: type: Album comparableFields: - fieldName: AlbumId booleanExpressionType: pg_int_comparison_exp - fieldName: ArtistId booleanExpressionType: pg_int_comparison_exp_with_is_null - field: Address booleanExpressionType: address_bool_exp comparableRelationships: - relationshipName: Artist booleanExpressionType: artist_bool_exp logicalOperators: enable: true isNull: enable: true graphql: typeName: app_album_bool_exp ``` ```yaml kind: BooleanExpressionType version: v1 definition: name: pg_int_comparison_exp operand: scalar: type: Int comparisonOperators: - name: equals argumentType: String! - name: _in argumentType: [String!]! dataConnectorOperatorMapping: - dataConnectorName: postgres_db dataConnectorScalarType: String operatorMapping: equals: _eq logicalOperators: enable: true isNull: enable: true graphql: typeName: app_postgres_int_bool_exp ``` <!-- What is this PR trying to accomplish (and why, if it's not obvious)? --> <!-- Consider: do we need to add a changelog entry? --> ### How Remove feature flag, unhide JsonSchema items, fix a few missing bits of JsonSchema the tests didn't warn us about before. <!-- How is it trying to accomplish it (what are the implementation steps)? --> V3_GIT_ORIGIN_REV_ID: dd3055d926fdeb7446cd57085679f2492a4358a1
2024-07-01 18:28:27 +03:00
- Added a flag, `--partial-supergraph`, which instructs the metadata resolver to
prune relationships to unknown subgraphs rather than failing to resolve
Enable `BooleanExpressionType`s (#783) <!-- The PR description should answer 2 (maybe 3) important questions: --> ### What # BooleanExpressionType A new metadata kind `BooleanExpressionType` can now be defined. These can be used in place of `ObjectBooleanExpressionType` and `DataConnectorScalarRepresentation`, and allow more granular control of comparison operators and how they are used. The old metadata types still work, but will eventually be deprecated. ```yaml kind: BooleanExpressionType version: v1 definition: name: album_bool_exp operand: object: type: Album comparableFields: - fieldName: AlbumId booleanExpressionType: pg_int_comparison_exp - fieldName: ArtistId booleanExpressionType: pg_int_comparison_exp_with_is_null - field: Address booleanExpressionType: address_bool_exp comparableRelationships: - relationshipName: Artist booleanExpressionType: artist_bool_exp logicalOperators: enable: true isNull: enable: true graphql: typeName: app_album_bool_exp ``` ```yaml kind: BooleanExpressionType version: v1 definition: name: pg_int_comparison_exp operand: scalar: type: Int comparisonOperators: - name: equals argumentType: String! - name: _in argumentType: [String!]! dataConnectorOperatorMapping: - dataConnectorName: postgres_db dataConnectorScalarType: String operatorMapping: equals: _eq logicalOperators: enable: true isNull: enable: true graphql: typeName: app_postgres_int_bool_exp ``` <!-- What is this PR trying to accomplish (and why, if it's not obvious)? --> <!-- Consider: do we need to add a changelog entry? --> ### How Remove feature flag, unhide JsonSchema items, fix a few missing bits of JsonSchema the tests didn't warn us about before. <!-- How is it trying to accomplish it (what are the implementation steps)? --> V3_GIT_ORIGIN_REV_ID: dd3055d926fdeb7446cd57085679f2492a4358a1
2024-07-01 18:28:27 +03:00
#### Boolean Expression Types
A new metadata kind `BooleanExpressionType` can now be defined. These can be
used in place of `ObjectBooleanExpressionType` and
`DataConnectorScalarRepresentation`, and allow more granular control of
comparison operators and how they are used.
```yaml
kind: BooleanExpressionType
version: v1
definition:
name: album_bool_exp
operand:
object:
type: Album
comparableFields:
- fieldName: AlbumId
booleanExpressionType: pg_int_comparison_exp
- fieldName: ArtistId
booleanExpressionType: pg_int_comparison_exp_with_is_null
- field: Address
booleanExpressionType: address_bool_exp
comparableRelationships:
- relationshipName: Artist
booleanExpressionType: artist_bool_exp
logicalOperators:
enable: true
isNull:
enable: true
graphql:
typeName: app_album_bool_exp
```
```yaml
kind: BooleanExpressionType
version: v1
definition:
name: pg_int_comparison_exp
operand:
scalar:
type: Int
comparisonOperators:
- name: equals
argumentType: String!
- name: _in
argumentType: [String!]!
dataConnectorOperatorMapping:
- dataConnectorName: postgres_db
dataConnectorScalarType: String
operatorMapping:
equals: _eq
logicalOperators:
enable: true
isNull:
enable: true
graphql:
typeName: app_postgres_int_bool_exp
```
- Add flag to (`--expose-internal-errors`) toggle whether to expose internal
errors. ([#759](https://github.com/hasura/v3-engine/pull/759))
#### Aggregates of Array Relationships
Aggregates of array relationships can now be defined by specifying an
`aggregate` in the `Relationship`'s target. Note that this is only supported
when the target of the relationship is a `Model`. You must also specify the
`aggregateFieldName` under the `graphql` section.
```yaml
kind: Relationship
version: v1
definition:
name: invoices
sourceType: Customer
target:
model:
name: Invoice
relationshipType: Array
aggregate: # New!
aggregateExpression: Invoice_aggregate_exp
description: Aggregate of the customer's invoices
mapping:
- source:
fieldPath:
- fieldName: customerId
target:
modelField:
- fieldName: customerId
graphql: # New!
aggregateFieldName: invoicesAggregate
```
- One can now configure the engine to set response headers for GraphQL requests,
if NDC function/procedures returns headers in its result
#### Field arguments
Add field arguments to the OpenDD `ObjectType`:
```yaml
kind: ObjectType
version: v1
definition:
name: institution
fields:
- name: id
type: Int!
- name: name
type: String!
arguments:
- name: hash
argumentType: String
- name: limit
argumentType: Int
- name: offset
argumentType: Int
graphql:
typeName: Institution
dataConnectorTypeMapping:
- dataConnectorName: custom
dataConnectorObjectType: institution
fieldMapping:
id:
column:
name: id
name:
column:
name: name
argumentMapping:
hash: hash
offset: offset
limit: limit
```
### Changed
### Fixed
- Engine now respects `relation_comparisons` capability, when generating GraphQL
schema for relationship fields in model filter
- The OpenDD schema for `DataConnectorLink` now references the correct version
(v0.1.4) of the NDC schema when using the NDC `CapabilitiesResponse` and
`SchemaResponse` types
## [v2024.06.13]
Initial release.
<!-- end -->
[Unreleased]: https://github.com/hasura/v3-engine/compare/v2024.07.18...HEAD
[v2024.07.18]: https://github.com/hasura/v3-engine/releases/tag/v2024.07.18
[v2024.07.10]: https://github.com/hasura/v3-engine/releases/tag/v2024.07.10
[v2024.07.04]: https://github.com/hasura/v3-engine/releases/tag/v2024.07.04
[v2024.06.13]: https://github.com/hasura/v3-engine/releases/tag/v2024.06.13