update changelog for v2.0.0-cloud.10 and older versions

Co-authored-by: Tirumarai Selvan <8663570+tirumaraiselvan@users.noreply.github.com>
Co-authored-by: Rikin Kachhia <54616969+rikinsk@users.noreply.github.com>
GitOrigin-RevId: 694f6a55d6464baaad70086aff1dee690d79e89f

docs/graphql/cloud/changelog.rst

@@ -15,18 +15,170 @@ Hasura Cloud Changelog
 Introduction
 ------------
 
-Please find the changelog (includes features, bug fixes, breaking change notifications, etc) of Hasura Cloud versions here. Note that Hasura Cloud includes everything from Hasura Open Source, hence the corresponding open source changelog is included in every version.  
+Please find the changelog (includes features, bug fixes, breaking change notifications, etc) of Hasura Cloud versions here.
+
+v2.0.0-cloud.10
+---------------
+
+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.
+
+.. thumbnail:: /img/graphql/cloud/changelog/cloud-monitoring.png
+   :alt: Monitoring overview page
+   :width: 556px
+
+
+- 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
+- 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
+- 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:
+
+.. code-block:: graphql
+
+  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
+
+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.
+
+.. thumbnail:: /img/graphql/cloud/changelog/integrate-newrelic.png
+   :alt: Monitoring overview page
+   :width: 556px
+
+- 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
 
 v2.0.0-cloud.1
 --------------
 
 Includes everything from OSS ``v2.0.0-alpha.1`` through ``v2.0.0-alpha.6``: https://github.com/hasura/graphql-engine/releases
 
-- Support centralized PG as the metadata database in cloud
+- Hasura Cloud now stores project metadata in its own managed database
 - Allow adding data source using env var
 - Add cache rate limiting to the query cache.
-- Add per query family cache metrics.
-- Add session variables to query cache keys.
+- Support queries with session variables in @cached.
 - Add endpoints for clearing the query cache and reading the query cache metrics.
 - Add read replicas UI
 
@@ -35,10 +187,54 @@ 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: This will be fixed in one of the upcoming versions.
+- **Multiple mutations in same request are not transactional**
 
-- Fixes behaviour of ``null`` in ``where`` expressions: 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.
+  *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.
 
-- Change in ``null`` join semantics in remote schema relationships : The remote schema will be queried only when all of the joining arguments are not ``null`` values. When there are ``null`` value(s) in any of the join arguments, 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.
+- **Semantics of explicit "null" values in "where" filters have changed**
 
-- Older Hasura versions as Remote Schemas: With v2.0, some of the auto-generated types have been extended. For example, ``String_comparison_exp`` has an additional ``regex`` input object field, this means if you have an older version of Hasura added as a Remote Schema then it will have a type conflict. You should upgrade all Hasura Remote Schemas to avoid such type conflicts.
+  According to the discussion in `issue 704 <https://github.com/hasura/graphql-engine/issues/704#issuecomment-635571407>`_, 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 <http://spec.graphql.org/June2018/#sec-Input-Object-Values>`__ 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.