Hasura - v2.10.0


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
  ...
}

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

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:

id | name | description
-- | ---- | -----------
1 | one | d1
2 | two | d2
3 | three | d3
4 | four | d4

After executing the query, the table will look like:

id | name | description
-- | ---- | -----------
1 | done | other
2 | second | other
3 | third | hello
4 | third | hello

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 https://github.com/hasura/graphql-engine/issues/2768.

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.

Details

date
Aug. 10, 2022, 5:35 p.m.
name
v2.10.0
type
Minor
👇
Register or login to:
  • 🔍View and search all Hasura releases.
  • 🛠️Create and share lists to track your tools.
  • 🚨Setup notifications for major, security, feature or patch updates.
  • 🚀Much more coming soon!
Continue with GitHub
Continue with Google
or