Hasura v1.0.0-beta.8 Release Notes

Release Date: 2019-10-22 // over 4 years ago
  • ๐Ÿ”„ Changelog

    ๐Ÿš€ Note: This release fixes the bugs with beta.7 and this is a combined changelog since beta.6.

    โฌ‡๏ธ Upgrading & downgrading

    โฌ†๏ธ You can upgrade to beta.8 from any version.

    ๐Ÿš€ Downgrading: You may need to manually run SQL scripts if your downgrade path involves a catalog change. Please see this for catalog history.

    ๐Ÿš€ Read more about upgrading and downgrading.

    Table of contents ๐Ÿ—‚

    Customize names of root fields and column fields

    Computed fields

    Create permissions with conditions spanning tables

    ๐ŸŽ Performance optimisations

    • Compress HTTP responses

    - Optmization for all subscriptions

    ๐Ÿ“š Annotate GraphQL schema for better documentation

    โšก๏ธ Update conditionally when using upsert

    ๐Ÿ‘ Better support for Postgres connection string parameters

    ๐Ÿ“„ Docs

    Others


    ๐Ÿฑ Customize the names of root fields and column fields ๐Ÿท

    This change allows customizing the names of root fields and the column fields in Hasura's GraphQL schema.

    0๏ธโƒฃ E.g. the default root field names generated for a table named author are:

    Queries/Subscriptions:

    • author
    • author_by_pk
    • author_aggregate

    Mutations:

    • insert_author
    • delete_author
    • โšก๏ธ update_author

    The above and the names of the column fields can now be customized.

    How to customize

    Console
    (to be available shortly)

    Customizing root fields names: Head to the Modify tab of the table whose generated root fields you want to change:

    Customizing column field names: Head to the Modify tab of the table whose column fields you want to alias and edit the column for an option to provide a custom name:

    ๐Ÿ“‡ Metadata API

    The v2 track_table allows you to specify all the customizations while tracking a table. Here's an example request:

    POST /v1/query HTTP/1.1Content-Type: application/json X-Hasura-Role: admin { "type": "track\_table", "version": 2, "args": { "table": "authors", "configuration": { "custom\_root\_fields": { "select": "authors", "select\_by\_pk": "author", "select\_aggregate": "authorStats", "insert": "createAuthors", "update": "updateAuthors", "delete": "removeAuthors" }, "custom\_column\_names": { "id": "authorId" } } } }
    

    For tables that have already been tracked, you can use the set_table_custom_fields metadata API:

    POST /v1/query HTTP/1.1Content-Type: application/json X-Hasura-Role: admin { "type": "set\_table\_custom\_fields", "version": 2, "args": { "table": { "name": "site\_employees", "schema": "rocc" }, "custom\_root\_fields": { "select": "authors", "select\_by\_pk": "author", "select\_aggregate": "authorStats", "insert": "createAuthors", "update": "updateAuthors", "delete": "removeAuthors" }, "custom\_column\_names": { "id": "authorId" } } }
    

    โš  โš ๏ธ Warnings โš ๏ธ

    • ๐Ÿ“‡ The original Postgres table and column names are used in metadata definitions for relationships, permissions etc.
    • Please ensure that your client apps are in sync with this change as once you begin using custom names, requests with the original field names will result in an error.
    • ๐Ÿ›  Known limitations: an error is thrown if the custom name and the original name of a column are the same. This is being fixed in #3154.

    Computed fields

    ๐Ÿ‘€ Computed fields are virtual values or objects that are dynamically computed and can be queried along with a table's columns. Computed fields are computed when requested for via SQL functions using other columns of the table and other custom inputs if needed. See pull request description.

    โž• Adding a computed field

    Computed fields are added to a table via SQL functions. Any SQL function which accepts table row type as one of the input arguments, returns base types (integer, Text, etc.) or SETOF <table-name> and not VOLATILE can be added as computed field.

    Example:-

    Let's say we have a table, author, that has two text columns, first_name and last_name, and we want to enrich the table with a virtual field that combines these columns into a new one, full_name. We can do this by adding a computed field:

    Define a SQL function called author_full_name:

     CREATE FUNCTION author\_full\_name(author\_row author) RETURNS TEXT AS $$ SELECT author\_row.first\_name || ' ' || author\_row.last\_name $$ LANGUAGE sql STABLE;
    

    โž• Add a computed field, full_name to the author table with the SQL function above using the following API.

    POST /v1/query HTTP/1.1Content-Type: application/json X-Hasura-Role: admin { "type":"add\_computed\_field", "args":{ "table":{ "name":"author", "schema":"public" }, "name":"full\_name", "definition":{ "function":{ "name":"author\_full\_name", "schema":"public" }, "table\_argument":"author\_row" } } }
    

    Query the data from author table along with its computed fields.

    query { author { idfirst\_namelast\_namefull\_name } }
    

    Response:

    { "data": { "author": [{ "id": 1, "first\_name": "Chris", "last\_name": "Raichael", "full\_name": "Chris Raichael" }] } }
    

    ๐Ÿ“‡ Please see docs to learn more about computed fields and their metadata API.


    ๐Ÿ”’ Create permissions with conditions spanning tables ๐Ÿ”

    ๐Ÿ— This change allows you to use data in unrelated tables to build a permission rule using the new _exists keyword. Let's use an example to see how this works:

    Say you have the following two tables:

    users

    Columns Type
    id Integer
    is_admin Boolean

    accounts

    Columns Type
    id Integer
    account_info Text

    and you want to restrict access to the accounts table to only those users who are "admins" i.e. the value of the is_admin column is true for the given user_id (which is sent in the X-Hasura-User-Id session variable).

    To compose a permission rule for this use-case, you can check if there's a row in the users table where id = X-Hasura-User-Id and is_admin = true:

    Like all the other operators, you can use logical operators (_and, _or and _not) to further restrict access to a subset of the rows.


    ๐ŸŽ Performance optimisations

    ๐Ÿฑ Compress HTTP responses ๐Ÿ—œ๏ธ

    HTTP responses from Hasura are now compressed (using gzip) by default whenever supported by the requesting client. In anecdotal tests, we've noticed approximately 10X compression in response payloads with negligible overhead for handling compression in the server and in client apps.

    ๐Ÿšค This should be especially useful to handle introspection queries on large datasets. We haven't yet benchmarked these changes in scenarios where network latency is a significant factor in overall latency, and any reports from the community on this front will be much appreciated!

    ๐Ÿฑ Optmization for all subscriptions ๐ŸŽš

    ๐Ÿ›  The previous iteration of this change only optimised subscriptions that did not use non-scalar variables. This has now been fixed, and requests with non-scalar variable values, such as the following, are now multiplexed if they generate the same SQL:

    subscription latest\_tracks($condition: tracks\_bool\_exp!) { tracks(where: $tracks\_bool\_exp) { idtitle } }
    

    ๐Ÿ“š Annotate GraphQL schema for better documentation ๐Ÿ–

    ๐Ÿ“„ You can now annotate your GraphQL schema for better readability by adding comments to your Postgres schema elements i.e. tables, views, columns and functions. These comments will be displayed in the Docs window of GraphiQL:

    Note : Currently, you can add comments for tables, views and column names using the console, but for functions you'll need to run a SQL query that does the same (support for this will be added to the console shortly).


    Update conditionally when using upsert (where clause in on_conflict input object)

    โšก๏ธ When using upsert, you can now conditionally update only a subset of rows using the new optional where clause in the on_conflict input object. Here's an example mutation:

    mutation { insert\_item( objects: {itemId:"1234", creationEpochSeconds: 1567026834}, on\_conflict: { constraint: item\_pkey, update\_columns: [itemId, creationEpochSeconds] where: {creationEpochSeconds: {\_lt: 1567026834 }} }) { affected\_rows } }
    

    ๐Ÿ‘ Better support for Postgres connection string parameters ๐Ÿ”Œ

    ๐Ÿ‘ Native support for the database connection string is now available and you can leverage the optional parameters in the string with Hasura. Examples of parameters you can now use:

    • application_name
    • ssl
    • connection_timeout
    • IPv6 (host address for the GraphQL engine -> Postgres connection)

    ๐Ÿ‘€ Please see this for details on parameters.


    ๐Ÿ“„ Docs ๐Ÿ“–

    Modelling teams and user security with Hasura (author: @elgordino)

    Public GraphQL queries with Hasura (unauthenticated users) (author: @mikewheaton)

    Building file upload/downloads for your Hasura app(author: @elitan)


    Others

    ๐Ÿš€ This release also includes bug-fixes and other minor changes.

    A big shoutout to:

    • @lorenzo for extending the graceful shutdown behaviour to WebSocket connections
    • @abn for disables auto-update checks when the cli is used in the entrypoint script for the cli-migrations container