Changelog

Introducing Apollo Federation v1 support (experimental)

HGE can now be used as a subgraph in an Apollo federated GraphQL server.
You can read more about this feature in the docs.

This is an experimental feature (can be enabled by setting
HASURA_GRAPHQL_EXPERIMENTAL_FEATURES: apollo_federation). This is supported
over all databases. To expose a table in an Apollo federated gateway, we need
to enable Apollo federation in its metadata. This can be done via the
*_track_table metadata API or via Modify Table page in console.

Enabling Apollo Federation on a table would add the @key directive in the GraphQL schema with
fields argument set to the primary key of the table (say id), i.e:

type user @key(fields: "id") {
  id: Int!
  name: String
  ...
}

Update multiple records for Postgres

We are introducing a new way to allow updating multiple records in the same
transaction for Postgres sources (#2768).

For example, the following query can be used to run the equivalent of two
update_by_pk in a single transaction:

update_artist_many(
  updates: [
    { 
      where: { id: { _eq: 1 } },
      _set: { name: "new name", description: "other" }
    },
    { 
       where: { id: { _eq: 2 } },
      _set: { name: "new name" }
    }
  ]
) {
  affected_rows
  returning {
    name
  }
}

However, this feature allows arbitrary updates, even when they overlap:

update_artist_many(
  updates: [
    { 
      where: { id: { _lte: 3 } },
      _set: { name: "first", description: "other" }
    },
    { 
      where: { id: { _eq: 2 } },
      _set: { name: "second" }
    },
    { 
      where: { id: { _gt: 2 } },
      _set: { name: "third", description: "hello" }
    },
    { 
      where: { id: { _eq: 1 } },
      _set: { name: "done" }
    }
  ]
) {
  affected_rows
  returning {
    id
    name
  }
}

Given the table looked like this before the query:

After executing the query, the table will look like:

The returned data will look like this:

{
  "data": {
    "update_artist_many": [
      {
        "affected_rows": 3,
        "returning": [
          {
            "id": 1,
            "name": "first"
          },
          {
            "id": 2,
            "name": "first"
          },
          {
            "id": 3,
            "name": "first"
          }
        ]
      },
      {
        "affected_rows": 1,
        "returning": [
          {
            "id": 2,
            "name": "second"
          }
        ]
      },
      {
        "affected_rows": 2,
        "returning": [
          {
            "id": 3,
            "name": "third"
          },
          {
            "id": 4,
            "name": "third"
          }
        ]
      },
      {
        "affected_rows": 1,
        "returning": [
          {
            "id": 1,
            "name": "done"
          }
        ]
      }
    ]
  }
}

The way it works is:

• we allow arbitrary where clauses (just like in a regular update)
• we allow arbitrary updates (_set, _inc, etc., depending on the field
  type)
• we run each update in sequence, in a transaction (if one of them fails,
  everything is rolled back)
• we collect the return value of each query and return a list of results

Please submit any feedback you may have for this feature at #2768.

Possible breaking change in case of conflicts with fields generated by the multiple record update feature

The new multiple record update feature described above introduces potential naming conflicts in your GraphQL schema. This feature
generates new root fields of the format <table_name>_updates. The types of these new fields can conflict with existing types in the schema,
for example, with the types of the root fields of another table named <table_name>_updates if it exists. In such a scenario, an upgrade to
versions >v2.10 will fail.

A workaround for this would be rename / add a custom_name to the table that causes the conflict.

Update: An option to disable the update multiple records feature to avoid these conflicts has been added via in the
v2.14.0-beta.1 release with the introduction of the hide_update_many_fields option to the --experimental-features flag / HASURA_GRAPHQL_EXPERIMENTAL_FEATURES env var.

Behaviour changes

• server: When providing a JSON path in a JWT claims map, you can now use
  double-quotes as well as single-quotes. Escaped characters in strings will now
  be honored appropriately, in the same way as JSON.

• server: In certain error messages, JSON paths will use double-quotes instead
  of single-quotes to represent field access.

  For example, instead of $.args['$set'], you will see $.args["$set"].

• cli: Use 2-spaces indent for GraphQL content in metadata instead of tabs (#8469)

  Example:

  Old Behaviour metadata/query_collections.yml	New Behaviour metadata/query_collections.yml
  - name: allowed-queries definition: queries: - name: getAlbums query: | query getAlbums { albums { id title } }	- name: allowed-queries definition: queries: - name: getAlbums query: | query getAlbums { albums { id title } }

Bug fixes and improvements

• server: Kriti basicFunctions now available for REST Connectors and Webhook Transforms
• server: Fix bug where Hasura SQL trigger was not dropped when MS SQL Server source is dropped
• server: Delete event trigger related database SQL triggers from tables when they are untracked
• server: Use root_field_namespace as prefix for remote schema (fix #8438)
• server: Fix prefix/suffix behaviour for graphql-default naming convention (fix #8544)
• server: Fix namespace visibility during introspection (fix #8434)
• server: Create missing SQL triggers, if any, while reloading metadata and startup.
• server: Fix name/enum transformation bugs in graphql-default naming convention (fix #8640)
• server: Parameterize array variables in generated SQL for queries and subscriptions
• server: Make postgres-client-cert fields: sslcert, sslkey and sslpassword optional
• server: Add *_update_source API to update configuration of a connected database (See docs)
• server: Changes to the Rest Endpoints OpenAPI specification:
  • The nullability of items in the output is now always correctly reported
  • Scalars other than UUID are more consistently inlined
  • Objects now have a title and, when available, the same description as in the GraphQL schema
• server: Bump Kriti package version to support optional variable lookup in string interpolation (fix #8574)
• server: Generate unique intermediate column names in PostgreSQL SQL queries to workaround PostgreSQL's identifier length limitation (fix #3796)
• console: Hide TimescaleDB internal schemas from data tab for connected TimescaleDB databases
• console: Support naming convention in source customization for PostgreSQL DBs
• console: Fix bug where "Analyze" button in the API explorer would stay in analyzing state after analyze failed
• console: Fix missing remote database relationship info for databases other than default on new table relationships page
• build: Changes to the hasura/graphql-engine Docker image:
  • Default graphql-engine docker images (hasura/graphql-engine:<VERSION>) now use an Ubuntu base instead of Debian.
  • Debian flavour of images (hasura/graphql-engine:<VERSION>.debian) are still published to Docker Hub.
  • CentOS flavour of images (hasura/graphql-engine:<VERSION>.centos) are no longer supported.