All Versions
101
Latest Version
Avg Release Cycle
18 days
Latest Release
-

Changelog History
Page 2

  • v2.8.2 Changes

    πŸ› Bug fixes and improvements

    • βͺ server: revert allow casting most postgres scalar types to strings in comparison expressions (#8617)
  • v2.8.1 Changes

    πŸ› Bug fixes and improvements

    • server: fix bug that had disabled expression-based indexes in Postgres variants (fix #8601)
  • v2.8.0 Changes

    Disabling query/subscription root fields

    When a table is tracked in graphql-engine, three root fields are generated automatically namely <table>, <table>_by_pk and <table>_aggregate in the query and the subscription root. You can now control which root fields are exposed for a given role by specifying them in the select permission.

    The main use-case for this feature is to disable APIs that access the table directly but which still need to be tracked so that:

    1. It can be accessed via a relationship to another table
    2. It can be used in select permissions for another table via a relationship

    For such use-cases, we can disable all the root fields of the given table. This can be done by setting the select permission as follows:

    {
       "role": "user",
       "permission": {
         "columns": [
           "id",
           "name"
         ],
         "filter": {},
         "allow_aggregations": true,
         "query_root_fields": [],
         "subscription_root_fields": []
       }
     }
    

    Another use-case is to allow a role to directly access a table only if it has access to the primary key value. This can be done by setting the select permission as follows:

    {
       "role": "user",
       "permission": {
         "columns": [
           "id",
           "name"
         ],
         "filter": {},
         "allow_aggregations": false,
         "query_root_fields": ["select_by_pk"],
         "subscription_root_fields": ["select_by_pk"]
       }
     }
    

    πŸš€ Note that console support for this permission will be released later.

    Introducing naming conventions (experimental)

    Now, users can specify the naming convention of the auto-generated names in the HGE. This is an experimental feature (enabled by setting HASURA_GRAPHQL_EXPERIMENTAL_FEATURES: naming_convention) and is supported for postgres databases only for now. There are two naming conventions possible: | Naming Convention | Field names | Type names | Arguments | Enum values | |-------------------|-------------|-------------|------------|-------------| 0️⃣ | hasura-default | Snake case | Snake case | Snake case | as defined | 0️⃣ | graphql-default | Camel case | Pascal case | Camel case | Uppercased |

    Suppose there is a table called my_table and it has columns id, date_of_birth, last_seen, then with 0️⃣ graphql-default naming convention we will get the following auto-generated API:

    query {
      myTable(orderBy: {dateOfBirth: asc}, limit: 10) {
        id
        dateOfBirth
        lastSeen
      }
    }
    

    πŸ”§ To configure the naming convention for a source, set the naming convention in source customisation while adding the source:

    {
      "resource_version": 2,
      "metadata": {
        "version": 1,
        "sources": [
          {
            "name": "default",
            "kind": "postgres",
            "tables": [],
            "configuration": {},
            "customization": {
              "naming_convention": "graphql-default"
            }
          }
        ]
      }
    }
    

    0️⃣ To set the default naming convention globally, use the environment variable HASURA_GRAPHQL_DEFAULT_NAMING_CONVENTION. Note 0️⃣ that the global default can be overridden by the source customisation setting mentioned above.

    Note: Custom field names and custom table names will override the naming convention (i.e. if the custom table name is my_table and naming_convention is graphql-default, the field names generated will be my_table, my_tableByPk, my_tableAggregate and so on).

    Behaviour Changes

    • πŸ“‡ cli: change the ordering used for object fields in metadata files to alphabetical order

    Example: Server Metadata (JSON) Old behaviour (YAML) New Behaviour (YAML) { "function": { "schema": "public", "name": "search_albums" } } function: schema: public name: search_albums function: name: search_albums schema: public

    πŸ› Bug fixes and improvements

    • server: fix create event trigger failure for MSSQL sources on a table with a table name that is a reserved MSSQL keyword.
    • server: errors from /healthz endpoint are now logged with more details
    • πŸ”’ server: do not expand environment variable references in logs or API responses from remote schemas, actions and event triggers for security reasons
    • ⚑️ server: introduce backend_only permissions for update and delete mutations (fix #5275)
    • πŸ‘ server: add support for scalar array response type in actions
    • πŸ‘ server: add support for table computed fields in bigquery backends
    • server: fix failure when executing consecutive delete mutations on mssql (#8462)
    • πŸ›  server: bugfix: insertion of multiple empty objects should result in multiple entries (#8475)
    • πŸ›  server: allow schemas prefixed with pg, but not pg_ (fix hasura/graphql-engine#8435)
    • πŸ‘ console: add support for application/x-www-form-urlencoded in rest connectors (#8097)
    • βͺ server: restore the ability to do no-op upserts (#8260).
  • v2.8.0-beta.1 Changes

    Disabling query/subscription root fields

    When a table is tracked in graphql-engine, three root fields are generated automatically namely <table>, <table>_by_pk and <table>_aggregate in the query and the subscription root. You can now control which root fields are exposed for a given role by specifying them in the select permission.

    The main use-case for this feature is to disable APIs that access the table directly but which still need to be tracked so that:

    1. It can be accessed via a relationship to another table
    2. It can be used in select permissions for another table via a relationship

    For such use-cases, we can disable all the root fields of the given table. This can be done by setting the select permission as follows:

    {
       "role": "user",
       "permission": {
         "columns": [
           "id",
           "name"
         ],
         "filter": {},
         "allow_aggregations": true,
         "query_root_fields": [],
         "subscription_root_fields": []
       }
     }
    

    Another use-case is to allow a role to directly access a table only if it has access to the primary key value. This can be done by setting the select permission as follows:

    {
       "role": "user",
       "permission": {
         "columns": [
           "id",
           "name"
         ],
         "filter": {},
         "allow_aggregations": false,
         "query_root_fields": ["select_by_pk"],
         "subscription_root_fields": ["select_by_pk"]
       }
     }
    

    πŸš€ Note that console support for this permission will be released later.

    Introducing naming conventions (experimental)

    Now, users can specify the naming convention of the auto-generated names in the HGE. πŸ‘ This is an experimental feature and is supported for postgres databases only for now. There are two naming conventions possible: | Naming Convention | Field names | Type names | Arguments | Enum values | |-------------------|-------------|-------------|------------|-------------| 0️⃣ | hasura-default | Snake case | Snake case | Snake case | as defined | 0️⃣ | graphql-default | Camel case | Pascal case | Camel case | Uppercased |

    Suppose there is a table called my_table and it has columns id, date_of_birth, last_seen, then with 0️⃣ graphql-default naming convention we will get the following auto-generated API:

    query {
      myTable(orderBy: {dateOfBirth: asc}, limit: 10) {
        id
        dateOfBirth
        lastSeen
      }
    }
    

    πŸ”§ To configure the naming convention for a source, set the naming convention in source customisation while adding the source:

    {
      "resource_version": 2,
      "metadata": {
        "version": 1,
        "sources": [
          {
            "name": "default",
            "kind": "postgres",
            "tables": [],
            "configuration": {},
            "customization": {
              "naming_convention": "graphql-default"
            }
          }
        ]
      }
    }
    

    0️⃣ To set the default naming convention globally, use the environment variable HASURA_GRAPHQL_DEFAULT_NAMING_CONVENTION. Note 0️⃣ that the global default can be overridden by the source customisation setting mentioned above.

    Note: Custom field names and custom table names will override the naming convention (i.e. if the custom table name is my_table and naming_convention is graphql-default, the field names generated will be my_table, my_tableByPk, my_tableAggregate and so on).

    Behaviour Changes

    • πŸ“‡ cli: change the ordering used for object fields in metadata files to alphabetical order

    Example: Server Metadata (JSON) Old behaviour (YAML) New Behaviour (YAML) { "function": { "schema": "public", "name": "search_albums" } } function: schema: public name: search_albums function: name: search_albums schema: public

    πŸ› Bug fixes and improvements

    • server: errors from /healthz endpoint are now logged with more details
    • πŸ”’ server: do not expand environment variable references in logs or API responses from remote schemas, actions and event triggers for security reasons
    • ⚑️ server: introduce backend_only permissions for update and delete mutations (fix #5275)
    • πŸ‘ server: add support for scalar array response type in actions
    • πŸ‘ server: add support for table computed fields in bigquery backends
    • server: fix failure when executing consecutive delete mutations on mssql (#8462)
    • πŸ›  server: bugfix: insertion of multiple empty objects should result in multiple entries (#8475)
    • πŸ›  server: allow schemas prefixed with pg, but not pg_ (fix hasura/graphql-engine#8435)
    • πŸ‘ console: add support for application/x-www-form-urlencoded in rest connectors (#8097)
    • βͺ server: restore the ability to do no-op upserts (#8260).
  • v2.7.0 Changes

    Streaming subscriptions

    Streaming subscriptions can be used to subscribe only to the data which has been changed in the query. The streaming is done on the basis of a cursor, which is chosen by the user. πŸ‘€ See docs.

    πŸ›° Request payload:

    subscription GetUserLatestMessages ($user_id: uuid!) {
      messages_stream (
        cursor: {
          initial_value: {id: 0},
          ordering: ASC
        },
        batch_size: 1,
        where: {user_id: {_eq: $user_id}}
      ) {
        id
        message
      }
    }
    

    The above subscription streams the messages of the user corresponding to the user_id in batches of 1 message per batch.

    Suppose there are two messages to be streamed, then the server will send two responses as following:

    Response 1:

    {
      "data": [
        {
          "id": 1,
          "message": "How are you!"
        }
      ]
    }
    

    Response 2:

    {
      "data": [
        {
          "id": 5,
          "message": "I am fine"
        }
      ]
    }
    

    πŸ› Bug fixes and improvements

    • πŸ‘ server: add support for custom scalar in action output type (#4185)
    • πŸ‘ server: add support for MSSQL event triggers (#7228)
    • ⚑️ server: update pg_dump to be compatible with postgres 14 (#7676)
    • server: fix bug where timestamp values sent to postgres would erroneously trim leading zeroes (#8096)
    • πŸ“‡ server: fix metadata handling bug when event triggers were defined on tables that contained non lower-case alphabet characters (#8454)
    • server: avoid encoding 'varchar' values to UTF8 in MSSQL backends
    • server: fix dropping of nested typed null fields in actions (#8237)
    • πŸ“œ server: fix url/query date variable parsing bug in REST endpoints
    • server: make url/query variables in REST endpoints assume string if other types not applicable
    • 0️⃣ server: fix inserting empty objects with default values to postgres, citus, and sql server (#8475)
    • server: don't drop the SQL triggers defined by the graphql-engine when DDL changes are made using the run_sql API
    • console: new "add remote schema" page with GQL customization
    • 🚚 console: allow users to remove prefix / suffix / root field namespace from a remote schema
    • console: fix console crash on adding pg sources with connection params through api (#8416)
    • cli: avoid exporting hasura-specific schemas during hasura init (#8352)
    • 🐎 cli: fix performance regression in migrate status command (#8398)
  • v2.7.0-beta.1 Changes

    πŸ› Bug fixes and improvements

    • server: don't drop the SQL triggers defined by the graphql-engine when DDL changes are made using the run_sql API
    • πŸ›  server: fixed a bug where timestamp values sent to postgres would erroneously trim leading zeroes (#8096)
    • server: fix bug when event triggers where defined on tables that contained non lower-case alphabet characters
    • server: avoid encoding 'varchar' values to UTF8 in MSSQL backends
    • πŸ‘ server: add support for MSSQL event triggers (#7228)
    • ⚑️ server: update pg_dump to be compatible with postgres 14 (#7676)
    • πŸ“œ server: fix parsing remote relationship json definition from 1.x server catalog on migration (fix #7906)
    • server: Don't drop nested typed null fields in actions (fix #8237)
    • πŸ›  server: fixes remote relationships on actions (fix #8399)
    • πŸ›  server: fixes url/query date variable bug in REST endpoints
    • server: makes url/query variables in REST endpoints assume string if other types not applicable
    • 0️⃣ server: fix inserting empty objects with default values to postgres, citus, and sql server (fix #8475)
    • server: allow casting most postgres scalar types to strings in comparison expressions (fix #8524)
    • console: add remote database relationships for views
    • πŸ›  console: bug fixes for RS-to-RS relationships
    • console: exclude _timescaledb_internal from db introspection sql, for performance reasons ()
    • 🚚 console: allow users to remove prefix / suffix / root field namespace from a remote schema
    • console: new "add remote schema" page (with GQL customization)
    • console: fix console crash on adding pg sources with connection params through api
    • cli: avoid exporting hasura-specific schemas during hasura init (#8352)
    • 🐎 cli: fix performance regression in migrate status command (fix #8398)
  • v2.6.2 Changes

    πŸ› Bug fixes and improvements

    • 0️⃣ server: fix inserting empty objects with default values to postgres, citus, and sql server (fix #8475)
  • v2.6.1 Changes

    • server: fix bug when event triggers where defined on tables that contained non lower-case alphabet characters (fix #8454)
    • πŸ”¨ server: refactor insert mutations IR use of "default values" (fixes #8443)
  • v2.6.0 Changes

    Known issue

    0️⃣ SQL Server: Mutation: Default values overwritten on insert under certain conditions. Will be addressed in 2.5.2 and 2.6.1.

    Announcing GraphQL Joins

    We are delighted to announce Hasura’s data federation capabilities that accelerate the API development process by creating a single GraphQL schema from multiple data sources such as databases and remote GraphQL APIs. This allows you to query and mutate across federated data sources in real-time without writing any custom code. In addition, we can leverage many of Hasura’s powerful features from Hasura CE and Hasura Cloud. Hasura’s field level permissions for remote schemas applies for joins as well, allowing for tightly controlled data disclosure when federating sources. Leverage Hasura Cloud’s caching directive to instantly put caching in front of multiple remote GraphQL schemas.

    πŸ’₯ Breaking changes

    The query and raw-query field from http-logs for metadata requests are removed by default. Use HASURA_GRAPHQL_ENABLE_METADATA_QUERY_LOGGING to re-enable those fields.

    πŸ› Bug fixes and improvements

    • server: removed 'query' and 'raw-query' field from logs for metadata queries by default. Use HASURA_GRAPHQL_ENABLE_METADATA_QUERY_LOGGING to re enable those fields.
    • πŸ“‡ server: clear_metadata now correctly archives event triggers and the drop source API drops indirect dependencies created by remote relationships when the dependent source is dropped.
    • server: fix inserting values into columns with case sensitive enum types for PostgreSQL/Citus backends (fix #4014)
    • server: remote relationships can be defined on and to Microsoft SQL Server tables
    • πŸ›  server: fix issues with JSON key encoding for remote schemas (fixes #7543 and #8200)
    • server: fix Microsoft SQL Server insert mutation when relationships are used in check permissions (fix #8225)
    • πŸ”¨ server: refactor GraphQL query static analysis and improve OpenAPI warning messages
    • server: avoid a resource leak when connecting to PostgreSQL fails
    • πŸ“œ server: fix parsing remote relationship json definition from 1.x server catalog on migration (fix #7906)
    • server: Don't drop nested typed null fields in actions (fix #8237)
    • πŸ›  server: fixes remote relationships on actions (fix #8399)
    • ⚑️ server: update pg_dump to be compatible with Postgres 14 (#7676)
    • πŸ‘ console: add support for setting aggregation query permissions for Microsoft SQL Server
    • πŸ‘ console: add support for RS-to-DB and RS-to-RS relationships to Remote Schemas
    • 🚚 console: removed the need for clicking the Modify btn before editing a remote schema (#1193, #8262)
    • πŸ‘ console: add remote database relationships support for views
    • πŸ“‡ cli: fix remote schema metadata formatting issues (#7608)
    • πŸ“‡ cli: fix query collections metadata formatting issues (#7616)
    • 🐎 cli: fix performance regression in migrate status command (fix #8398)
    • πŸ“„ docs: support for graphql-ws is considered GA
  • v2.6.0-beta.2 Changes

    πŸ› Bug fixes and improvements

    • πŸ“œ server: fix parsing remote relationship json definition from 1.x server catalog on migration (fix #7906)
    • server: Don't drop nested typed null fields in actions (fix #8237)
    • πŸ›  server: fixes remote relationships on actions (fix #8399)
    • ⚑️ server: update pg_dump to be compatible with postgres 14 (#7676)
    • console: add remote database relationships for views
    • 🐎 cli: fix performance regression in migrate status command (fix #8398)