Announcing Hasura 2.0.0-alpha.8

Announcing Hasura 2.0.0-alpha.8

We are excited to announce the release of Hasura 2.0.0-alpha.8!

This continues our journey towards 2.0 being fully feature stable. And, while ‘alpha’ in name, it is not alpha in quality. However, we do use this signifier to denote that it is a work in progress and invite feedback about any problems you may experience.

• Hasura 2.0.0-alpha.8 docker quickstart
• Hasura 2.0.0-alpha.8 changelog
• Getting Started with Hasura Cloud

A Summary of Releases

More will be coming, in the near future, about the Hasura release process holistically. We have historically announced our releases via Discord and updates to the GitHub release page. As adoption continues to increase, we believe this is insufficient for the future.

To that end, we will begin to blog for each release (even if it is only small) so that you can track releases via blog, twitter (@HasuraHQ), Discord, and the Github Release page. In these posts, we will highlight a few specific elements of each release, but the exhaustive list of features and improvements is always in the changelog. Given this change, this blog will cover not only but also some of the capability in alpha.7.

Overview

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.

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

This release provides a way to revert the engine to its previous behaviour: if the HASURA_GRAPHQL_V1_BOOLEAN_NULL_COLLAPSE environment variable is set to "true", null values in boolean expression will behave like they did in v1 for the following operators: _is_null, _eq, _neq, _in, _nin, _gt, _lt, _gte, _lte.

Transactions for Postgres mutations - alpha.7

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, to prevent any breaking changes or regressions for Hasura v1 users upgrading to v2.

Conclusion

Please use the docker target "hasura/graphql-engine:v2.0.0-alpha.8", try it out, let us know what works and what needs improvement. You can find us on Twitter (@HasuraHQ) and in Github. For ad-hoc conversation, feel free to join us on the Hasura Community Discord.

And, if you want to get started now with the latest stable release, check out the deployment simplicity of Hasura Cloud.