- Server: Fix erroneous schema type for action output fields (fix #6631)
- Server: Introduce ``HASURA_GRAPHQL_GRACEFUL_SHUTDOWN_TIMEOUT`` env var for server config. This configures the time (default: 60s) to wait for any in-flight scheduled events, event trigger events and async actions to complete before shutting down. After this time, any in-flight events will be marked as pending.
- Server: Fix a regression from V1 and allow string values for most Postgres column types
- Server: Sanitise event trigger and scheduled trigger logs to omit possibly sensitive request body and headers
- Server: Fix parsing of values for Postgres char columns (fix #6814)
- Server: Explaining/analyzing a query now works for mssql sources
- 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
- CLI: Fix regression - ``metadata apply —dry-run`` was overwriting local metadata files with metadata on server when it should just display the differences.
- Dashboard: Add env var ``HASURA_GRAPHQL_V1_BOOLEAN_NULL_COLLAPSE`` (default: false)
v2.0.0-cloud.9
--------------
Server: All ``/query`` APIs now require admin privileges
v2.0.0-cloud.8
--------------
Server: Format the values of ``injectEventContext`` as hexadecimal string instead of integer (fix #6465)
v2.0.0-cloud.7
--------------
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 <https://www.postgis.net/docs/manual-3.1/reference.html#reference_sfcgal>`_ which may depend on the PostGIS distribution used.
- Server: Format Tracing values inside trace_log to string.
- Server: Fix issue with scheduled trigger logs
v2.0.0-cloud.6
--------------
- Miscellaneous fixes
v2.0.0-cloud.5
--------------
- Console: Add request preview for REST endpoints
v2.0.0-cloud.4
--------------
Support for null values in boolean expressions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In v2, we introduced a breaking change, that aimed at fixing a `long-standing issue <https://github.com/hasura/graphql-engine/issues/704>`_: a null value in a boolean expression would always evaluate to ``True`` for all rows. For example, the following queries were all equivalent:
..code-block:: graphql
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:
..code-block:: graphql
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:
..code-block:: graphql
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
v2.0.0-cloud.3
--------------
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:
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
v2.0.0-cloud.2
--------------
Add New Relic APM integration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You can now export metrics and operation logs of your Hasura Cloud project to New Relic.
