NOTE: 1.4 is now 2.0

Changelog

Support for MSSQL Server

It's now possible to add a MSSQL Server as a source. In this version, only queries and subscriptions are supported.

Know issues

See #6607 for known issues on the CLI which should be fixed in the next release.

Using this release

Use the following docker image:

hasura/graphql-engine:v2.0.0-alpha.2

Changelog

1.4 is now 2.0

Hasura 1.4 has significant feature and product enhancements that warranted bumping the major version up! The new release is now called v2.0.0-alpha.1 (which would have been equivalent to v1.4.0-alpha.3).

However, there are no major user-facing breaking changes and users can upgrade Hasura 1.3 to 2.0 seamlessly. There are 2 minor behaviour changes (which only affects certain corner cases and has been requested from the community for long) in this release, please find the details in "Behaviour changes" section at the bottom.

Hasura 2.0 highlights

Multiple databases

Simultaneously add multiple Postgres databases:

Metadata storage separation

You can now store Hasura metadata in a separate (PG) database given by the environment variable
HASURA_GRAPHQL_METADATA_DATABASE_URL

Generalized backend

Generalization code to support different databases (“MS SQL server” being the first one we will release as a part of 2.0)

REST APIs

Support for creating idiomatic REST API endpoints from GraphQL query templates so that users can support non-GraphQL clients easily and integrate with their existing REST tooling.

Remote Schema Permissions

Role based schemas and argument presets (based on session variables) are now available for remote schemas.

Volatile functions as mutations/queries

You can now track VOLATILE Postgres functions as mutations (or even queries).

Other fixes and improvements:

server: add allow_inconsistent_metadata option to replace_metadata API to allow adding objects which are inconsistent
server: add "resource_version" field to metadata for concurrency control - disable lookup during migrations
server: add request field to webhook POST body containing the GraphQL query/mutation, its name, and any variables passed (close #2666)
server: add --websocket-compression command-line flag for enabling websocket compression (fix #3292)
server: some mutations that cannot be performed will no longer be in the schema (for instance, delete_by_pk mutations won't be shown to users that do not have select permissions on all primary keys) (#4111)
server: treat the absence of backend_only configuration and backend_only: false equally (closing #5059) (#4111)
server: accept only non-negative integers for batch size and refetch interval (close #5653) (#5759)
server: Configurable websocket keep-alive interval. Add --websocket-keepalive command-line flag and HASURA_GRAPHQL_WEBSOCKET_KEEPALIVE env variable (fix #3539)
server: introduce optional custom table name in table configuration to track the table according to the custom name. The set_table_custom_fields API has been deprecated, A new API set_table_customization has been added to set the configuration. (#3811)
server: support joining Int or String scalar types to ID scalar type in remote relationship
server: add support for regex operators (close #4317) (#6172)
server: do not block catalog migration on inconsistent metadata
server: various changes to ensure timely cleanup of background threads and other resources in the event of a SIGTERM signal.
server: fix issue with event triggers defined on a table which is partitioned (fixes #6261)
server: action array relationships now support the same input arguments (such as where or distinct_on) as usual relationships
server: action array relationships now support aggregate relationships
server: fix issue with non-optional fields of the remote schema being added as optional in the graphql-engine (fix #6401)
server: accept new config allowed_skew in JWT config to provide leeway for JWT expiry (fixes #2109)
server: always log the request_id at the detail.request_id path for both query-log and http-log (#6244)
server: fix issue with --stringify-numeric-types not stringifying aggregate fields (fix #5704)
server: terminate a request if time to acquire connection from pool exceeds configurable timeout (#6326)
server: support tracking of functions that return a single row (fix #4299)
console: allow user to cascade Postgres dependencies when dropping Postgres objects (close #5109) (#5248)
console: mark inconsistent remote schemas in the UI (close #5093) (#5181)
console: add onboarding helper for new users
console: add option to flag an insertion as a migration from Data section (close #1766) (#4933)
console: down migrations improvements (close #3503, #4988) (#4790)
console: show only compatible postgres functions in computed fields section (close #5155) (#5978)
console: add session argument field for computed fields (close #5154) (#5610)
console: add tree view for Data Tab UI
cli: add missing global flags for seed command (#5565)
cli: allow seeds as alias for seed command (#5693)
build: add test_server_pg_13 to the CI to run the server tests on Postgres v13 (#6070)

Behaviour changes

Multiple mutations in same request are not transactional

UPDATE (since v2.0.0-cloud.3): For only Postgres data source, multiple fields in a mutation will be run in one transaction to preserve backwards compatibility.
Semantics of explicit "null" values in "where" filters have changed

According to the discussion in issue 704, an explicit null value in a comparison input object will be treated as an error rather than resulting in the expression being evaluated to True.

For example: The mutation delete_users(where: {id: {_eq: $userId}}) { name } will yield an error if $userId is null instead of deleting all users.

UPDATE (since v2.0.0-cloud.10): The old behaviour can be enabled by setting an environment variable: HASURA_GRAPHQL_V1_BOOLEAN_NULL_COLLAPSE: true.
Semantics of "null" join values in remote schema relationships have changed

In a remote schema relationship query, the remote schema will be queried when all of the joining arguments are not null values. When there are null value(s), the remote schema won't be queried and the response of the remote relationship field will be null. Earlier, the remote schema was queried with the null value arguments and the response depended upon how the remote schema handled the null arguments but as per user feedback, this behaviour was clearly not expected.
Order of keys in objects passed as "order_by" operator inputs is not preserved

The order_by operator accepts an array of objects as input to allow ordering by multiple fields in a given order, i.e. [{field1: sortOrder}, {field2: sortOrder}] but it is also accepts a single object with multiple keys as an input, i.e. {field1: sortOrder, field2: sortOrder}. In earlier versions, Hasura's query parsing logic used to maintain the order of keys in the input object and hence the appropriate order by clauses with the fields in the right order were generated .

As the GraphQL spec mentions that input object keys are unordered, Hasura v2.0's new and stricter query parsing logic doesn't maintain the order of keys in the input object taking away the guarantee of the generated order by clauses to have the fields in the given order.

For example: The query fetch_users(order_by: {age: desc, name: asc}) {id name age} which is intended to fetch users ordered by their age and then by their name is now not guaranteed to return results first ordered by age and then by their name as the order_by input is passed as an object. To achieve the expected behaviour, the following query fetch_users(order_by: [{age: desc}, {name: asc}]) {id name age} should be used which uses an array to define the order of fields to generate the appropriate order by clause.
Incompatibility with older Hasura version remote schemas

With v2.0, some of the auto-generated schema types have been extended. For example, String_comparison_exp has an additional regex input object field. This means if you have a Hasura API with an older Hasura version added as a remote schema then it will have a type conflict. You should upgrade all Hasura remote schemas to avoid such type conflicts.
Migrations are not executed under a single transaction

While applying multiple migrations, in earlier Hasura CLI versions all migration files were run under one transaction block. i.e. if any migration threw an error, all the previously successfully executed migrations would be rolled back. With Hasura CLI v2.0, each migration file is run in its own transaction block but all the migrations are not executed under one. i.e. if any migration throws an error, applying further migrations will be stopped but the other successfully executed migrations up till that point will not be rolled back.

Using this release

Use the following docker image:

hasura/graphql-engine:v2.0.0-alpha.1

NOTE: 1.4 is now 2.0

Changelog

This is the next alpha release for v1.4.0. This includes few metadata related features and many refactors to support other database backends.

Inconsistent Metadata

Add allow_inconsistent_metadata option to replace_metadata API. This will replace metadata even if there are inconsistency errors, returning a 200 response code and is_consistent and inconsistent_objects keys in the response body.

Bug fixes and improvements

server: fix issue of not exposing mutation functions to the admin role when function permissions are inferred (fix #6503)
server: add "resource_version" field to metadata for concurrency control - disable lookup during migrations
console: add tree view for Data tab UI
cli: restore v2 metadata support

Using this release

Use the following docker image:

hasura/graphql-engine:v1.4.0-alpha.2

Changelog

This releases fixes bugs reported in v1.3.4-beta.2 and few minor features.

Fixes and improvements

server: fix handling of empty array values in relationships of set_custom_types API (fix #6357)
server: fix issue with non-nullable remote schema fields (fix #6401)
server: handle event trigger PG functions to work with partitioned tables (#6261)
server: allow fragments to use variables (fix #6303)
server: fix query actions issue used with relationship and configured with permissions (fix #6385)
server: accept new config allowed_skew in JWT config to provide leeway in JWT expiry (close #2109)
server: fix action relationship type and input arguments (closes #6402)
console: allow URLs with templated environment variable for data events (close #6231)
console: add support for computed fields for views (close #6168)
console: export data as CSV/JSON from Browser page (close #1438, close #5158)

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.4-beta.3

NOTE: 1.4 is now 2.0

Changelog

(Detailed changelog to be added soon)

Highlights

Multiple Postgres Sources - You can now add multiple PG databases on the same Hasura instance
Metadata storage separation - You can now store Hasura metadata in a separate (PG) database given by the env variable HASURA_GRAPHQL_METADATA_DATABASE_URL
Volatile functions as mutations/queries - You can now track VOLATILE Postgres functions as mutations (or even queries)
Remote Schema Permissions - You can now do role-based access control for remote schemas using field masking and argument presets. You need to enable this using HASURA_GRAPHQL_ENABLE_REMOTE_SCHEMA_PERMISSIONS: "true" env variable.
REST Endpoint Support - You can now create REST endpoints on top of your GraphQL API. (Note: console support is pending)
Heterogeneous Execution - You can now query Postgres databases and remote schema(s) in the same operation.
CLI config v3 - To accomodate for multiple PG databases, the CLI project structure has been upgraded to v3. You can use the hasura scripts update-project-v3 command to upgrade your v2 project structure to v3. (You should keep a backup of the v2 project as the spec for the v3 config might change in future alpha versions)

Support for CLI config v1 has been deprecated in this release. CLI config v2 will still be supported.

Known bug: The CLI is not able to handle config v2 structured projects. This will be fixed in the next release.

Note that as this release is still in alpha, a cli-migrations-v3 docker image to be used in CI/CD has not been released.

Note: This is an alpha release. Pls do not use this in production.

Using this release

Use the following docker image:

hasura/graphql-engine:v1.4.0-alpha.1

Changelog

This is the second beta release for v1.3.4 which includes some improvements and fixes reported issues.

Fixes and improvements

server: fix primary key mutations issue reported in v1.3.4-beta.1 (fix #6255)
server: customize tracking tables with a custom name (#5719)
server: improve subscription performance by tracking only required session variables in multiplexed queries (#4329)
server: do not block catalog migration on inconsistent metadata (closes #6272, fix #5117)

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.4-beta.2

Changelog

This release contains the PDV refactor (#4111) which significantly improves the way schema parsing and validation are handled. This also fixes few long-standing behavioral issues which are listed below:

Bug fixes (which have potential breaking changes)

(Fixes behaviour of pathological case) The semantics of explicit null values in where filters have changed according to the discussion in issue 704: an explicit null value in a comparison input object will be treated as an error rather than resulting in the expression being evaluated to True. For instance: delete_users(where: {id: {_eq: $userId}}) { name } will yield an error if $userId is null instead of deleting all users.
(Changes null join semantics) In a remote schema relationship query, the remote schema will be queried when all of the joining arguments are not null values. When there are null value(s), the remote schema won't be queried and the response of the remote relationship field will be null. Earlier, the remote schema was queried with the null value arguments and the response depended upon how the remote schema handled the null arguments but as per user feedback, this behaviour was clearly not expected.

Other fixes and improvements

server: support joining Int, String or UUID scalar types to ID type in remote relationship
The validation of required headers has been fixed (closing #14 and #3659):
- if a query selects table bar through table foo via a relationship, the required permissions headers will be the union of the required headers of table foo and table bar (we used to only check the headers of the root table);
- if an insert does not have an on_conflict clause, it will not require the update permissions headers.

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.4-beta.1

Changelog

Server - Support for mapping session variables to default JWT claims

Some auth providers do not let users add custom claims in JWT. In such cases, the server can take a JWT configuration option called claims_map to specify a mapping of Hasura session variables to values in existing claims via JSONPath or literal values.

Example:-

Consider the following JWT claim:

  {
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true,
    "iat": 1516239022,
    "user": {
      "id": "ujdh739kd",
      "appRoles": ["user", "editor"]
    }
  }

The corresponding JWT config can be:

  {
    "type":"RS512",
    "key": "<The public Key>",
    "claims_map": {
      "x-hasura-allowed-roles": {"path":"$.user.appRoles"},
      "x-hasura-default-role": {"path":"$.user.appRoles[0]","default":"user"},
      "x-hasura-user-id": {"path":"$.user.id"}
    }
  }

You can also use this technique to avoid writing any custom code for adding Hasura claims in your JWT token.

Metadata Types SDK

The types and documentation comments for Metadata V2 have been converted into JSON/YAML Schema, and used to autogenerate type definitions for popular languages.

This enables users to build type-safe tooling in the language of their choice around Metadata interactions and automations.

Additionally, the JSON/YAML Schemas can be used to provide IntelliSense and autocomplete + documentation when interacting with Metadata YAML/JSON files.

For a more comprehensive overview, please see the readme located here

Sample Code

import { TableEntry } from "../generated/HasuraMetadataV2"

const newTable: TableEntry = {
  table: { schema: "public", name: "user" },
  select_permissions: [
    {
      role: "user",
      permission: {
        limit: 100,
        allow_aggregations: false,
        columns: ["id", "name", "etc"],
        computed_fields: ["my_computed_field"],
        filter: {
          id: { _eq: "X-Hasura-User-ID" },
        },
      },
    },
  ],
}

IntelliSense Example

Bug fixes and improvements

server: allow remote relationships joining type column with [type] input argument as spec allows this coercion (fixes #5133)
server: add action-like URL templating (i.e. {{WEBHOOK_ENV_VAR}}) for event triggers and remote schemas (fixes #2483)
server: change created_at column type from timestamp to timestamptz for scheduled triggers tables (fix #5722)
server: allow configuring timeouts for actions (fixes #4966)
server: fix bug which arised when renaming a table which had a manual relationship defined (close #4158)
server: limit the length of event trigger names (close #5786)
NOTE: If you have event triggers with names greater than 42 chars, then you should update their names to avoid running into Postgres identifier limit bug (#5786)
server: enable HASURA_GRAPHQL_PG_CONN_LIFETIME by default to reclaim memory
server: fix issue with tracking custom functions that return SETOF materialized view (close #5294) (#5945)
server: allow remote relationships with union, interface and enum type fields as well (fixes #5875) (#6080)
server: Fix fine-grained incremental cache invalidation (fix #3759) (#6027)
This issue could cause enum table values to sometimes not be properly reloaded without restarting graphql-engine. Now a reload_metadata API call (or clicking “Reload enum values” in the console) should consistently force a reload of all enum table values.
server: fix event trigger cleanup on deletion via replace_metadata (fix #5461) (#6137)
WARNING: This can cause significant load on PG on startup if you were affected by this bug. Delay in starting up is expected.
cli: fix bug in metadata apply which made the server aquire some redundant and unnecessary locks (close #6115)
cli: fix cli-migrations-v2 image failing to run as a non root user (close #4651, close #5333)
cli: fix issue with cli binary on latest Mac (Big Sur) (fix #5462)

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.3

Changelog

We’ve fixed an issue where the column masking in select permissions were not applied for scalar computed fields (#5696). This issue affects you only if you’re using scalar valued computed fields and if you’re not using allow-lists.

We recommend you upgrade to v1.3.2 if you’re using v1.3.0 or v1.3.1

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.2

Changelog

This is the first patch release for v1.3. This fixes few bugs and includes general refactors.

Breaking change

Headers from environment variables starting with HASURA_GRAPHQL_ are not allowed in event triggers, actions & remote schemas.

If you do have such headers configured, then you must update the header configuration before upgrading.

Bug fixes and improvements

server: fix failing introspection query when an enum column is part of a primary key (fixes #5200)
server: disallow headers from env variables starting with HASURA_GRAPHQL_ in event triggers, actions & remote schemas (#5519)
WARNING: This might break certain deployments. See Breaking change section above.
server: bugfix to allow HASURA_GRAPHQL_QUERY_PLAN_CACHE_SIZE of 0 (#5363)
server: support only a bounded plan cache, with a default size of 4000 (closes #5363)
server: add logs for action handlers (#5471)
server: add request/response sizes in event triggers (and scheduled trigger) logs (#5463)
server: change startup log kind db_migrate to catalog_migrate (#5531)
console: handle nested fragments in allowed queries (close #5137) (#5252)
console: update sidebar icons for different action and trigger types (#5445)
console: make add column UX consistent with others (#5486)
cli: improve error messages thrown when metadata apply fails (#5513)
cli: fix issue with creating seed migrations while using tables with upper-case letters (closes #5532) (#5549)
build: introduce additional log kinds for cli-migrations image (#5529)

Using this release

Use the following docker image:

hasura/graphql-engine:v1.3.1

Releases: hasura/graphql-engine

v2.0.0-alpha.2

Changelog

Support for MSSQL Server

Know issues

Using this release

Uh oh!

v2.0.0-alpha.1

Changelog

1.4 is now 2.0

Hasura 2.0 highlights

Multiple databases

Metadata storage separation

Generalized backend

REST APIs

Remote Schema Permissions

Volatile functions as mutations/queries

Other fixes and improvements:

Behaviour changes

Using this release

Uh oh!

v1.4.0-alpha.2

NOTE: 1.4 is now 2.0

Changelog

Inconsistent Metadata

Bug fixes and improvements

Using this release

Uh oh!

v1.3.4-beta.3

Changelog

Fixes and improvements

Using this release

Uh oh!

v1.4.0-alpha.1

NOTE: 1.4 is now 2.0

Changelog

Highlights

Using this release

Uh oh!

v1.3.4-beta.2

Changelog

Fixes and improvements

Using this release

Uh oh!

v1.3.4-beta.1

Changelog

Bug fixes (which have potential breaking changes)

Other fixes and improvements

Using this release

Uh oh!

v1.3.3

Changelog

Server - Support for mapping session variables to default JWT claims

Metadata Types SDK

Bug fixes and improvements

Using this release

Uh oh!

v1.3.2

Changelog

Using this release

Uh oh!

v1.3.1

Changelog

Breaking change

Bug fixes and improvements

Using this release

Uh oh!