Hasura Cloud Changelog¶

New Overview page for Monitoring¶

The new Overview page gives a birds eye view of current load, historical API performance, source health and associated metrics.

• Server: Fix MSSQL table metadata SQL, return empty array for empty rows (fix #1226)
• Server: Aggregation fields are now supported on mssql
• Server: restore proper batching behavior in event trigger processing so that at most 2x batch events are checked out at a time
• Server: Fix regression on_conflict was missing in the schema for inserts in tables where the current user has no columns listed in their update permissions (fix #6804)
• Server: Fix one-to-one relationship bug which prevented adding one-to-one relationships which didn’t have the same column name for target and source
• Server: Fix query execution of custom function containing a composite argument type
• Server: Fix a bug in query validation that would cause some queries using default variable values to be rejected (fix #6867)
• Server: Custom URI schemes are now supported in CORS config (fix #5818)
• Server: REST endpoint bugfix for UUID url params
• Server: Support disabling GraphQL introspection for specified roles
• Console: Fix Postgres table creation when table has a non-lowercase name and a comment (#6760)
• Console: Read-only modify page for mssql
• Console: Filter out partitions from track table list and display partition info
• Console: Fixes an issue where no schemas are listed on an MSSQL source
• Console: Fix missing headers in event trigger invocations page which logged out Cloud console
• CLI: Fix regression - metadata apply —dry-run was overwriting local metadata files with metadata on server when it should just display the differences.
• CLI: Add support for api_limits metadata object
• Dashboard: Add env var HASURA_GRAPHQL_V1_BOOLEAN_NULL_COLLAPSE (default: false)

Support for 3D PostGIS Operators¶

We now support the use of the functions ST_3DDWithin and ST_3DIntersects in boolean expressions. Note that ST_3DIntersects requires PostGIS be built with SFCGAL support which may depend on the PostGIS distribution used.

• Server: Format Tracing values inside trace_log to string.
• Server: Fix issue with scheduled trigger logs

Support for null values in boolean expressions¶

In v2, we introduced a breaking change, that aimed at fixing a long-standing issue: a null value in a boolean expression would always evaluate to True for all rows. For example, the following queries were all equivalent:

delete_users(where: {_id: {_eq: null}})  # field is null, which is as if it were omitted
delete_users(where: {_id: {}})           # object is empty, evaluates to True for all rows
delete_users(where: {})                  # object is empty, evaluates to True for all rows
delete_users()                           # delete all users

This behaviour was unintuitive, and could be an unpleasant surprise for users that expected the first query to mean “delete all users for whom the id column is null”. Therefore in v2, we changed the implementation of boolean operators to reject null values, as we deemed it safer:

delete_users(where: {_id: {_eq: null}})  # error: argument of _eq cannot be null

However, this change broke the workflows of [some of our users](https://github.com/hasura/graphql-engine/issues/6660) who were relying on this property of boolean operators. This was used, for instance, to _conditionally_ enable a test:

query($isVerified: Boolean) {
  users(where: {_isVerified: {_eq: $isVerified}}) {
    name
  }
}

• Console: Add custom_column_names to track_table request with replaced invalid characters
• Console: Add details button to the success notification to see inserted row

Transactions for Postgres mutations¶

With v2 came the introduction of heterogeneous execution: in one query or mutation, you can target different sources: it is possible, for instance, in one mutation, to both insert a row in a table in a table on Postgres and another row in another table on MSSQL:

mutation {
  # goes to Postgres
  insert_author_one(object: {name: "Simon Peyton Jones"}) {
    name
  }

  # goes to MSSQL
  insert_publication_one(object: {name: "Template meta-programming for Haskell"}) {
    name
  }
}

However, heterogeneous execution has a cost: we can no longer run mutations as a transaction, given that each part may target a different database. This is a regression compared to v1.

While we want to fix this by offering, in the future, an explicit API that allows our users to choose when a series of mutations are executed as a transaction, for now we are introducing the following optimisation: when all the fields in a mutation target the same Postgres source, we will run them as a transaction like we would have in v1.

• Server: Add connection acquisition latency metrics for Postgres databases
• Server: Log the parametrized_query_hash value in http-log logs
• Server: Fix a bug preventing some MSSQL foreign key relationships from being tracked
• Console: Data sidebar bug fixes and improvements
• CLI: Fix seeds incorrectly being applied to databases in config-v3
• CLI: Add --all-databases flag for migrate apply, this allows applying migrations on all connected databases in one go
• Docs: Add Hasura v2 upgrade guide
• CI/CD: Add cli-migrations config-v3 image

Add New Relic APM integration¶

You can now export metrics and operation logs of your Hasura Cloud project to New Relic.

• Server: Add replace_configuration option (default: false) in the add source API payload
• Server: Add a comment field for actions
• Server: Accept GeoJSON for MSSQL geometry and geography operators
• Console: Add a comment field for actions

Breaking changes¶

This version includes breaking changes from previous version (i.e v1.3.3-cloud.x).

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