graphql-engine/v3/changelog.md
Daniel Harvey a95eaa4c4f Allow object types to be used as comparison operator arguments (#895)
<!-- The PR description should answer 2 (maybe 3) important questions:
-->

### What

This allows object types to be used as arguments for comparison
operators. This is useful for Elasticsearch's `range` operator, which
allows passing an object like `{ gt: 1, lt: 100 }` to an `integer` field
in order to filter items that are greater than `1` and less than `100`.

This PR has the nice side effect of dropping the requirement to use
information from scalar `BooleanExpressionType`s in place of
`DataConnectorScalarTypes`, which we only required because we were not
looking up the comparable operator information in scalar boolean
expression types correctly.

<!-- What is this PR trying to accomplish (and why, if it's not
obvious)? -->

<!-- Consider: do we need to add a changelog entry? -->

### How

Previously, when using `ObjectBooleanExpressionType` and
`DataConnectorScalarRepresentation`, we had no information about the
argument types of comparison operators (ie, what values should I pass to
`_eq`?), and so inferred this by looking up the comparison operator in
the data connector schema, then looking for a
`DataConnectorScalarRepresentation` that tells us what OpenDD type that
maps to.

Now, with `BooleanExpressionType`, we have this information provided in
OpenDD itself:

```yaml
kind: BooleanExpressionType
version: v1
definition:
  name: Int_comparison_exp
  operand:
    scalar:
      type: Int
      comparisonOperators:
        - name: _eq
          argumentType: Int! # This is an OpenDD type
        - name: _within
          argumentType: WithinInput!
        - name: _in
          argumentType: "[Int!]!"
```

Now we look up this information properly, as well as tightening up some
validation around relationships that was making us fall back to the old
way of doing things where the user had failed to provide a
`comparableRelationship` entry.

This means

a) we can actually use object types as comparable operator types
b) scalar boolean expression types aren't used outside the world of
boolean expressions, which is a lot easier to reason about.

<!-- How is it trying to accomplish it (what are the implementation
steps)? -->

V3_GIT_ORIGIN_REV_ID: ad5896c7f3dbf89a38e7a11ca9ae855a197211e3
2024-07-29 12:13:33 +00:00

7.5 KiB

Changelog

Unreleased

Added

  • New NoAuth mode in auth config can be used to provide a static role and session variables to use whilst running the engine, to make getting started easier.

Fixed

  • Fix use of object types as comparison operator arguments by correctly utilising user-provided OpenDD types.

Changed

  • Introduced AuthConfig v2. This new version removes role emulation in engine (allowRoleEmulationBy) field.

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

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.

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

  • Added a flag, --partial-supergraph, which instructs the metadata resolver to prune relationships to unknown subgraphs rather than failing to resolve

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.

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
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)

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.

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:

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.