diff --git a/docs/docs/actions/action-handlers.mdx b/docs/docs/actions/action-handlers.mdx index 13e30f48715..fdd8a117972 100644 --- a/docs/docs/actions/action-handlers.mdx +++ b/docs/docs/actions/action-handlers.mdx @@ -177,7 +177,7 @@ In your Hasura server, add the action secret as an environment variable, say `AC For your action, add a header that will act as an action secret. - + Head to the `Actions -> [action-name]` tab in the console and scroll down to `Headers`. You can now configure an action diff --git a/docs/docs/actions/action-permissions.mdx b/docs/docs/actions/action-permissions.mdx index dfc3053e439..4a59b6eb592 100644 --- a/docs/docs/actions/action-permissions.mdx +++ b/docs/docs/actions/action-permissions.mdx @@ -21,7 +21,7 @@ As with the other fields in the GraphQL schema, users need to be given access to ## Set action permissions - + Head to the `Actions -> [action-name] -> Permissions` tab in the console. diff --git a/docs/docs/actions/action-relationships.mdx b/docs/docs/actions/action-relationships.mdx index 7135e66af3c..412191c1ad9 100644 --- a/docs/docs/actions/action-relationships.mdx +++ b/docs/docs/actions/action-relationships.mdx @@ -79,7 +79,7 @@ See more details at [custom object type relationships](/actions/types.mdx) You can create relationships for custom output types by: - + Head to the `Actions -> [action-name] -> Relationships` tab in the console for the action returning the output type. diff --git a/docs/docs/actions/codegen/index.mdx b/docs/docs/actions/codegen/index.mdx index a8555ece46c..a6e05c788d0 100644 --- a/docs/docs/actions/codegen/index.mdx +++ b/docs/docs/actions/codegen/index.mdx @@ -28,7 +28,7 @@ contributions from the community. ## Generating handler code for your action {#actions-codegen-execute} - + Head to the `Actions -> [action-name] -> Codegen` tab in the console diff --git a/docs/docs/actions/create.mdx b/docs/docs/actions/create.mdx index 71e36ab16d7..53865fef61c 100644 --- a/docs/docs/actions/create.mdx +++ b/docs/docs/actions/create.mdx @@ -32,8 +32,8 @@ Let's look at **examples** for mutation and query type actions. ## Setup - - + + There is no setup required for defining actions via the console. @@ -88,7 +88,7 @@ Let's start with a mutation that accepts a username and password, and returns an Start with defining the mutation and the required types. These types will reflect in the GraphQL schema. - + Go to the `Actions` tab on the console and click on `Create`. This will take you to a page like this: @@ -237,7 +237,7 @@ You can deploy this code somewhere and get the URI. For getting started quickly, Now, set the handler for the action: - + Set the value of the `handler` field to the above endpoint. @@ -283,7 +283,7 @@ If you are running Hasura using Docker, ensure that the Hasura Docker container Finally, to save the action: - + Hit `Create`. @@ -333,7 +333,7 @@ Let's start with a basic query that accepts a list of numbers and returns their Start with defining the query and the required types. These types will reflect in the GraphQL schema. - + Go to the `Actions` tab on the console and click on `Create`. This will take you to a page like this: @@ -450,13 +450,10 @@ The above definition means: You can also use Type Generator feature to generate the types for your action: - + -Insert JSON samples for the request and the response, click "Insert Types" and Hasura generates the GraphQL types for you. +Insert JSON samples for the request and the response, click "Insert Types" and Hasura generates the GraphQL types for +you. ### Step 2: Create the action handler @@ -491,7 +488,7 @@ You can deploy this code somewhere and get the URI. For getting started quickly, Now, set the handler for the action: - + Set the value of the `handler` field to the above endpoint. @@ -529,7 +526,7 @@ e.g. `https://my-handler-endpoint/addNumbers` can be templated to `{{ACTION_BASE Finally, to save the action: - + Hit `Create`. diff --git a/docs/docs/actions/derive.mdx b/docs/docs/actions/derive.mdx index 8c6d902d544..4dd70eddc15 100644 --- a/docs/docs/actions/derive.mdx +++ b/docs/docs/actions/derive.mdx @@ -54,7 +54,7 @@ mutation insertAuthor($name: String) { Now that we have a mutation with arguments being accepted as variables, we can derive our action: - + Head to the `API` tab of the console and paste / generate your query in the GraphiQL window. @@ -121,7 +121,7 @@ The action name will be picked up from the argument of the command and not the m For a derived action, Hasura can generate the relevant handler code to delegate the action back to the original operation. - + Head to the `Actions -> [action-name] -> Codegen` tab in the console diff --git a/docs/docs/actions/rest-connectors.mdx b/docs/docs/actions/rest-connectors.mdx index e23de93c331..0e4a5623d74 100644 --- a/docs/docs/actions/rest-connectors.mdx +++ b/docs/docs/actions/rest-connectors.mdx @@ -43,7 +43,7 @@ REST Connectors are supported in Hasura GraphQL Engine versions `v2.1.0` and abo REST Connectors can be configured either when creating a new action or editing an existing one. See the transform options [here](#action-transform-types): - + Go to the `Actions` tab on the console and create or modify an action. Scroll down to `Configure REST Connectors` @@ -188,7 +188,7 @@ You can transform your: You can change the request method to adapt to your API's expected format. - + In the `Configure REST Connectors` section, click on `Add Request Options Transform`: @@ -287,7 +287,7 @@ You can also provide query params to add to the URL. You can use the [Kriti templating language](/api-reference/kriti-templating.mdx) to construct any string values here. - + In the `Configure REST Connectors` section, click on `Add Request Options Transform`: @@ -412,7 +412,7 @@ request body to `x_www_form_urlencoded` formats. If you are using a `GET` request, you might want to not send any request body, and additionally not send a `content-type` header to the webhook. You can do that using the disable body feature. - + In the `Configure REST Connectors` section, click on `Add Request Options Transform`, and convert the `Request Method` @@ -515,7 +515,7 @@ X-Hasura-Role: admin You can transform Request Body to `application/json` format using the following steps: - + In the `Configure REST Connectors` section, click on `Add Payload Transform`. By default console sends the body as @@ -615,7 +615,7 @@ While doing `x_www_form_urlencoded` transformation, please note that as all chan when calling the API, so you will need to remove the default `application/json` header and add a `application/x-www-form-urlencoded` header. - + In the `Configure REST Connectors` section, click on `Add Payload Transform`. Change the dropdown next to @@ -730,8 +730,8 @@ X-Hasura-Role: admin ### Response Body -You can transform the default body of your HTTP API response by configuring a response transform template. This can -be used to match the output types defined in your Action with your HTTP API. +You can transform the default body of your HTTP API response by configuring a response transform template. This can be +used to match the output types defined in your Action with your HTTP API. :::info Note @@ -739,16 +739,12 @@ Response transforms are applicable only for JSON responses. ::: - + In the `Configure REST Connectors` section, click on `Add Response Transform`: - + Hit `Create Action` to apply your changes. @@ -817,6 +813,7 @@ X-Hasura-Role: admin } } ``` + @@ -824,7 +821,7 @@ X-Hasura-Role: admin Let's integrate Auth0's management API to update the profile of a user: - + Go to the `Actions` tab on the console and create or modify an action. Scroll down to `Configure REST Connectors` diff --git a/docs/docs/api-reference/kriti-templating.mdx b/docs/docs/api-reference/kriti-templating.mdx index 7b6d46d230e..34f4e10d2c8 100644 --- a/docs/docs/api-reference/kriti-templating.mdx +++ b/docs/docs/api-reference/kriti-templating.mdx @@ -9,9 +9,9 @@ sidebar_label: Kriti Templating sidebar_position: 13 --- -import Tabs from "@theme/Tabs"; -import TabItem from "@theme/TabItem"; -import Thumbnail from "@site/src/components/Thumbnail"; +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import Thumbnail from '@site/src/components/Thumbnail'; # Kriti Templating in Hasura @@ -19,14 +19,17 @@ import Thumbnail from "@site/src/components/Thumbnail"; Kriti allows transformation of JSON via templating during the Hasura GraphQL Engine lifecycle. -Kriti has a JSON-like syntax that allows for the creation of JSON values via direct-construction, reference and branching structures. +Kriti has a JSON-like syntax that allows for the creation of JSON values via direct-construction, reference and +branching structures. There are two main ways that Kriti templates are used: -* String interpolation for fields -* Payload transformation +- String interpolation for fields +- Payload transformation -String interpolation can also be used inside Kriti payload transformations, so only payload examples will be used here. But note that when a field provides Kriti interpolation capabilities you can't use the full capabilities of Kriti templates, just the interpolation capabilities. +String interpolation can also be used inside Kriti payload transformations, so only payload examples will be used here. +But note that when a field provides Kriti interpolation capabilities you can't use the full capabilities of Kriti +templates, just the interpolation capabilities. :::info Note @@ -38,15 +41,15 @@ See [Kriti's README.md on GitHub](https://github.com/hasura/kriti-lang#kriti-lan At present, Kriti templating is available for: -* [Action REST Connectors](/actions/rest-connectors.mdx) -* [Event Triggers REST Connectors](/event-triggers/rest-connectors.mdx) -* [Cron Triggers REST Connectors](/scheduled-triggers/create-cron-trigger.mdx#rest-connectors) +- [Action REST Connectors](/actions/rest-connectors.mdx) +- [Event Triggers REST Connectors](/event-triggers/rest-connectors.mdx) +- [Cron Triggers REST Connectors](/scheduled-triggers/create-cron-trigger.mdx#rest-connectors) ### Example The following is an example of using Kriti templates for an Action REST Connector: - + Open the Hasura Console, head to the `Actions` tab, and click the `Create` button to open the page. @@ -54,8 +57,8 @@ Open the Hasura Console, head to the `Actions` tab, and click the `Create` butto Add a REST connector payload and configure and test the associated template. @@ -102,8 +105,8 @@ X-Hasura-Role: admin } ``` -The template field is a string that represents a template in the language reflected in the template_engine field. -In this case: +The template field is a string that represents a template in the language reflected in the template_engine field. In +this case: ```json { @@ -113,21 +116,21 @@ In this case: } } ``` + - ## Capabilities and behavior The functionality of Kriti templates can be broken down into the following categories: -* JSON Value Construction -* Control Flow -* Value Interpolation -* String Interpolation -* Path Accessors -* Optional Chaining -* Functions +- JSON Value Construction +- Control Flow +- Value Interpolation +- String Interpolation +- Path Accessors +- Optional Chaining +- Functions Most Kriti-specific functionality is introduced through the use of a `{{ ... }}` syntax. @@ -139,13 +142,15 @@ For example, the following is a valid Kriti template and JSON document: ```json { - "a": [1,2,3], + "a": [1, 2, 3], "b": "hello world" } ``` + ### Value interpolation -Values can be interpolated in place of a normal JSON value. For example, the "b" field uses interpolation rather than a literal value here: +Values can be interpolated in place of a normal JSON value. For example, the "b" field uses interpolation rather than a +literal value here: ```json { @@ -175,7 +180,8 @@ Conditional logic and loops are supported: ### Path references -As part of interpolation and control-flow you may reference data via paths, of which a variable is a special case. The scope from which a path is looked up is either top-level, or expanded via control flow. +As part of interpolation and control-flow you may reference data via paths, of which a variable is a special case. The +scope from which a path is looked up is either top-level, or expanded via control flow. For example, if the variable `foo` contained the value `1`, you could reference it like so: @@ -197,7 +203,8 @@ or: ### Optional chaining -You may also use optional chaining to traverse into fields that may not be present. The value is `Null` if the field is not present: +You may also use optional chaining to traverse into fields that may not be present. The value is `Null` if the field is +not present: ```json { "a": {{ bar?.x }} } @@ -227,8 +234,9 @@ These use the `foo(...)` syntax: } ``` -The [Function Reference](#kriti-function-reference) section details the functions available by default. Note that there can be additional functions and values in the scope depending on the template context. These will be documented in the relevant documentation section. - +The [Function Reference](#kriti-function-reference) section details the functions available by default. Note that there +can be additional functions and values in the scope depending on the template context. These will be documented in the +relevant documentation section. ## Function reference {#kriti-function-reference} @@ -263,9 +271,10 @@ Output: ### size Returns: + - the length of an array or string - the number of keys of an object -- the value of a number +- the value of a number - `1` for `true` and `0` for `false` - `0` for `null` @@ -279,8 +288,8 @@ Input: } ``` - Output: - +Output: + ```json { "array": 1, @@ -310,11 +319,7 @@ Output: ```json { - "array": [ - 3, - 2, - 1 - ], + "array": [3, 2, 1], "number": 0.25, "string": "fdsa" } @@ -363,13 +368,9 @@ Output: ```json { - "array": [ - 2, - 3 - ], + "array": [2, 3], "string": "sdf" } - ``` ### toCaseFold @@ -414,7 +415,6 @@ Output: { "string": "abcd" } - ``` ### toUpper @@ -437,7 +437,6 @@ Output: { "string": "ABCD" } - ``` ### toTitle @@ -502,14 +501,8 @@ Output: ```json { "object": [ - [ - "a", - 1 - ], - [ - "b", - 2 - ] + ["a", 1], + ["b", 2] ] } ``` @@ -530,11 +523,7 @@ Output: ```json { - "array": [ - 1, - 3, - 5 - ] + "array": [1, 3, 5] } ``` @@ -558,12 +547,7 @@ Output: ```json { - "arrays": [ - 1, - 2, - 3, - 4 - ], + "arrays": [1, 2, 3, 4], "objects": { "a": 1, "b": 3, @@ -575,7 +559,7 @@ Output: :::info Note -All of the above functions are also listed on the [Kriti GitHub README.md](https://github.com/hasura/kriti-lang/blob/main/README.md#basic-functions-collection). +All of the above functions are also listed on the +[Kriti GitHub README.md](https://github.com/hasura/kriti-lang/blob/main/README.md#basic-functions-collection). ::: - diff --git a/docs/docs/auth/authorization/basics.mdx b/docs/docs/auth/authorization/basics.mdx index a4c2a1ebe2e..dc175966a93 100644 --- a/docs/docs/auth/authorization/basics.mdx +++ b/docs/docs/auth/authorization/basics.mdx @@ -83,7 +83,7 @@ permissions. Now let's define an access control rule for the `authors` table for a role `user`. - + Head to the **Permissions** section of the table (`Data -> [table] -> Permissions` tab) and define permissions as shown diff --git a/docs/docs/auth/authorization/inherited-roles.mdx b/docs/docs/auth/authorization/inherited-roles.mdx index 96747f6538d..1284b79415d 100644 --- a/docs/docs/auth/authorization/inherited-roles.mdx +++ b/docs/docs/auth/authorization/inherited-roles.mdx @@ -44,7 +44,7 @@ For versions `v2.1.0-beta.1` and above, inherited roles are enabled by default. ## Creating inherited roles - + Go to the `Settings` tab (⚙) on the console and click on `Inherited Roles`. diff --git a/docs/docs/auth/authorization/permission-rules.mdx b/docs/docs/auth/authorization/permission-rules.mdx index 7a9912ebd1c..54a8403cf02 100644 --- a/docs/docs/auth/authorization/permission-rules.mdx +++ b/docs/docs/auth/authorization/permission-rules.mdx @@ -84,11 +84,7 @@ be read. In the case of `insert`, the boolean expression determines whether or n Row-level permissions are defined using operators, static values, values in columns (_including those in related tables or nested objects_) and session variables. - + #### Using column operators to build rules @@ -109,7 +105,7 @@ See the [API reference](/api-reference/syntax-defs.mdx#metadataoperator) for a l The following is an example of a simple boolean expression to restrict access for `select` to rows where the value in the `id` column is greater than 10: - + You can define permissions using boolean expressions on the Hasura Console as follows: @@ -119,9 +115,8 @@ You can define permissions using boolean expressions on the Hasura Console as fo -You can define permissions using boolean expressions in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file, eg: - +You can define permissions using boolean expressions in the +`metadata > databases > [database-name] > tables > [table-name].yaml` file, eg: ```yaml {8-10} - table: @@ -183,7 +178,7 @@ You can construct more complex boolean expressions using the `_and`, `_or` and ` **For example**, using the `_and` operator, you can construct a rule to restrict access for `select` to rows where the value in the `id` column is greater than 10 **and** the value in the `name` column starts with "a" or "A": - + You can define permissions using the `_and` operator on the Hasura Console as follows: @@ -197,8 +192,8 @@ You can define permissions using the `_and` operator on the Hasura Console as fo -You can define permissions using the `_and` operator in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file eg: +You can define permissions using the `_and` operator in the +`metadata > databases > [database-name] > tables > [table-name].yaml` file eg: ```yaml {8-11} - table: @@ -270,7 +265,7 @@ using the JWT configuration are available for constructing row-level permissions to construct a rule to restrict access for `select` to rows in the `articles` table where the value in the `id` column is equal to the value in the session variable (_assuming this variable is being used to indicate the author's ID_): - + You can define session variables in permissions on the Hasura Console: @@ -284,8 +279,8 @@ You can define session variables in permissions on the Hasura Console: -You can define session variables in permissions in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file, eg: +You can define session variables in permissions in the +`metadata > databases > [database-name] > tables > [table-name].yaml` file, eg: ```yaml {10-12} - table: @@ -359,7 +354,7 @@ called `agent` (_an author can have an agent_) and we want to allow users with t the authors who they manage in `authors` table. We can define the following permission rule that uses the aforementioned object relationship: - + You can use a nested object to build rules on the Hasura Console: @@ -373,8 +368,8 @@ You can use a nested object to build rules on the Hasura Console: -You add permissions using relationships or nested objects in the `metadata > databases > [database-name] > tables > -[table-name].yaml` eg: +You add permissions using relationships or nested objects in the +`metadata > databases > [database-name] > tables > [table-name].yaml` eg: ```yaml {8-11} - table: @@ -451,7 +446,7 @@ You can use the `_exists` operator to set a permission rule based on tables/view column in the `users` table is set to `true`. Let's assume the user's id is passed in the `X-Hasura-User-ID` session variable. - + You can set permissions using unrelated tables on the Hasura Console as follows: @@ -461,8 +456,8 @@ You can set permissions using unrelated tables on the Hasura Console as follows: -You can set permissions using unrelated tables in the `metadata > databases > [database-name] > tables > -[table-name].yaml`, eg: +You can set permissions using unrelated tables in the +`metadata > databases > [database-name] > tables > [table-name].yaml`, eg: ```yaml {7-15} - table: @@ -541,7 +536,7 @@ user's_ `id` _and has the_ `allow_article_create` _column set to true, allow acc Column-level permissions determine access to columns in the rows that are accessible based on row-level permissions. - + Column-level permissions are simple selections on the Hasura Console: @@ -551,8 +546,8 @@ Column-level permissions are simple selections on the Hasura Console: -You can set column-level permissions in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file, eg: +You can set column-level permissions in the `metadata > databases > [database-name] > tables > [table-name].yaml` file, +eg: ```yaml {7-11} - table: @@ -619,7 +614,7 @@ In this example, the role `author` has only partial access to columns of the acc In the case of `select` operations, the number of rows to be returned in the response can be limited using this configuration: - + You can set a row fetch limit on the Hasura Console as follows: @@ -629,8 +624,8 @@ You can set a row fetch limit on the Hasura Console as follows: -You can set a row fetch limit for a table in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file, eg: +You can set a row fetch limit for a table in the `metadata > databases > [database-name] > tables > [table-name].yaml` +file, eg: ```yaml {13} - table: @@ -695,7 +690,7 @@ In the above example, this configuration restricts the number of accessible rows In the case of `select` operations, access to [aggregation queries](/queries/postgres/aggregation-queries.mdx) can be enabled for a given role using this configuration. - + You can enable aggregation queries permissions on the Hasura Console as follows: @@ -705,8 +700,8 @@ You can enable aggregation queries permissions on the Hasura Console as follows: -You can allow aggregation query permissions in the `metadata > databases > [database-name] > tables > -[table-name].yaml` file, eg: +You can allow aggregation query permissions in the `metadata > databases > [database-name] > tables > [table-name].yaml` +file, eg: ```yaml {13} - table: @@ -773,7 +768,7 @@ While this is strictly not a permission configuration, defining access to it. This preset can be defined for `insert` and `update` operations. This configuration is also very useful to avoid sending sensitive user-information in the request and leverage session variables or static data instead. - + You can define column presets for either `insert` or `update` operations in the Hasura Console as follows: @@ -783,8 +778,8 @@ You can define column presets for either `insert` or `update` operations in the -You can define column presets for table columns in the `metadata > databases > [database-name] > -tables > [table-name].yaml`, eg: `public_users.yaml`: +You can define column presets for table columns in the +`metadata > databases > [database-name] > tables > [table-name].yaml`, eg: `public_users.yaml`: ```yaml {8-9} table: @@ -798,7 +793,6 @@ insert_permissions: id: x-hasura-User-Id columns: - id - ``` Apply the metadata by running: @@ -811,8 +805,8 @@ hasura metadata apply You can define column presets with either the [insert](/api-reference/syntax-defs.mdx#insertpermission) or -[update](/api-reference/syntax-defs.mdx#updatepermission) [permissions metadata API](/api-reference/metadata-api/permission.mdx). -Example using a Postgres db: +[update](/api-reference/syntax-defs.mdx#updatepermission) +[permissions metadata API](/api-reference/metadata-api/permission.mdx). Example using a Postgres db: ```http {15-20} POST /v1/metadata HTTP/1.1 @@ -855,19 +849,22 @@ This might be useful if you would like to hide a mutation from the public facing Setting `backend-only` is currently available for insert, update and delete mutations. - + You can set a mutate permission for a role as backend only in the Hasura Console as follows: - + -You can set a mutate permission for a role as backend only in the `metadata > -databases > [database-name] > tables > [table-name].yaml` file, eg: `public_users.yaml`: +You can set a mutate permission for a role as backend only in the +`metadata > databases > [database-name] > tables > [table-name].yaml` file, eg: `public_users.yaml`: ```yaml {10,14} table: @@ -878,7 +875,7 @@ insert_permissions: permission: check: {} columns: - - id + - id backend_only: true delete_permissions: - role: user @@ -891,8 +888,8 @@ delete_permissions: You can set a mutate permission for a role as backend only with the Metadata API and the - [insert](/api-reference/syntax-defs.mdx#insertpermission), [update](/api-reference/syntax-defs.mdx#updatepermission) - or [delete](/api-reference/syntax-defs.mdx#deletepermission) permissions. +[insert](/api-reference/syntax-defs.mdx#insertpermission), [update](/api-reference/syntax-defs.mdx#updatepermission) or +[delete](/api-reference/syntax-defs.mdx#deletepermission) permissions. ```http {19} POST /v1/metadata HTTP/1.1 @@ -930,7 +927,6 @@ and above. ::: - ### Disabling Root Fields {#disabling-root-fields} When you track a table in Hasura, by default it exposes all the root fields available to the role. However, sometimes @@ -949,22 +945,23 @@ Disabling root fields is supported in version `v2.8.0` and above. ::: - - + You can disable specific root fields for query and subscription by unchecking them in the Select permission for the table and role in Console as follows: - + -You can disable root fields for queries and subscriptions specifying which are available for the -`select_permissions` by updating the specific `metadata > databases > [database-name] > tables > [table-name].yaml` file -eg: +You can disable root fields for queries and subscriptions specifying which are available for the `select_permissions` by +updating the specific `metadata > databases > [database-name] > tables > [table-name].yaml` file eg: ```yaml {10-15} table: @@ -991,8 +988,8 @@ delete_permissions: :::info Note -Setting the value of `query_root_fields` or `subscription_root_fields` to `null` or not defining it at -all implies that all fields are allowed and an empty array means no fields are allowed. +Setting the value of `query_root_fields` or `subscription_root_fields` to `null` or not defining it at all implies that +all fields are allowed and an empty array means no fields are allowed. ::: @@ -1000,8 +997,8 @@ all implies that all fields are allowed and an empty array means no fields are a You can disable root fields for Select permissions with the -[permissions metadata API](/api-reference/metadata-api/permission.mdx) by specifying which should be available in -the `query_root_fields` and `subscription_root_fields` arrays, eg: +[permissions metadata API](/api-reference/metadata-api/permission.mdx) by specifying which should be available in the +`query_root_fields` and `subscription_root_fields` arrays, eg: ```http {16,17} POST /v1/metadata HTTP/1.1 @@ -1028,16 +1025,14 @@ X-Hasura-Role: admin :::info Note -Setting the value of `query_root_fields` or `subscription_root_fields` to `null` or not defining it at -all implies that all fields are allowed and an empty array means no fields are allowed. +Setting the value of `query_root_fields` or `subscription_root_fields` to `null` or not defining it at all implies that +all fields are allowed and an empty array means no fields are allowed. ::: - - #### Use cases ##### 1. Allow a table to be accessible only through a relationship @@ -1054,12 +1049,14 @@ We would like to configure permissions of the `guest` role such that they are on Modifying the select permission of the `articles` table: + - - -Note that `query_root_fields` and `subscription_root_fields` are set to `[]`, which means that the `guest` role -won't be able to access the `articles` table directly, but will be able to access it through the `articles` -relationship. +Note that `query_root_fields` and `subscription_root_fields` are set to `[]`, which means that the `guest` role won't be +able to access the `articles` table directly, but will be able to access it through the `articles` relationship. :::caution @@ -1078,7 +1075,11 @@ In this case, regardless of the permission on the table, only `_by_pk` sh This can be done in the following way: - + ##### 3. Disable subscription fields @@ -1086,7 +1087,11 @@ You can allow a role to only be able to make query and not subscription requests This can be done in the following way: - + :::info Additional Resources diff --git a/docs/docs/data-federation/apollo-federation.mdx b/docs/docs/data-federation/apollo-federation.mdx index 0f2df2b8be5..706e8bf5a24 100644 --- a/docs/docs/data-federation/apollo-federation.mdx +++ b/docs/docs/data-federation/apollo-federation.mdx @@ -10,6 +10,7 @@ keywords: - subgraph - data federation --- + import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; import Thumbnail from '@site/src/components/Thumbnail'; @@ -19,14 +20,14 @@ import Thumbnail from '@site/src/components/Thumbnail'; ## Introduction Hasura GraphQL engine supports the Apollo Federation v1 spec, so you can add Hasura as a subgraph in your Apollo -federated gateway. You can also use Hasura generated table types in your other subgraphs by enabling tables for -Apollo Federation explicitly. +federated gateway. You can also use Hasura generated table types in your other subgraphs by enabling tables for Apollo +Federation explicitly. :::caution Experimental Apollo Federation is an experimental feature and can be enabled by adding `apollo_federation` to the -`HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` [environment variable array](/deployment/graphql-engine-flags/reference.mdx) -or with the server flag `--experimental-feature`. +`HASURA_GRAPHQL_EXPERIMENTAL_FEATURES` [environment variable array](/deployment/graphql-engine-flags/reference.mdx) or +with the server flag `--experimental-feature`. ::: @@ -61,23 +62,20 @@ Other types such as action types, remote schema types, etc. cannot be extended t ::: - + Head to the `Data -> [table-name] -> Modify` tab in the console and toggle the switch in the `Enable Apollo Federation` section: - + To enable Apollo Federation using the Hasura CLI head to the particular -`/metadata/databases//tables/_.yaml` file and add the database configuration -as below: +`/metadata/databases//tables/_.yaml` file and add the database configuration as +below: ```yaml {6-7} table: @@ -96,8 +94,8 @@ hasura metadata apply -To extend the types using the [Hasura Metadata API](/api-reference/metadata-api/table-view.mdx), you can to enable -it with the particular `*_set_apollo_federation_config` call: +To extend the types using the [Hasura Metadata API](/api-reference/metadata-api/table-view.mdx), you can to enable it +with the particular `*_set_apollo_federation_config` call: ```http {16-18} POST /v1/metadata HTTP/1.1 diff --git a/docs/docs/databases/connect-db/cloud-connection-pooling.mdx b/docs/docs/databases/connect-db/cloud-connection-pooling.mdx index edfb92f8cee..78d8f5a935c 100644 --- a/docs/docs/databases/connect-db/cloud-connection-pooling.mdx +++ b/docs/docs/databases/connect-db/cloud-connection-pooling.mdx @@ -16,14 +16,14 @@ sidebar_class_name: cloud-icon import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -import Thumbnail from "@site/src/components/Thumbnail"; +import Thumbnail from '@site/src/components/Thumbnail';
Available on: Cloud
## Introduction -In Hasura, you get automatic connection pools for your database connections. Apart from the general performance benefits of -using pooled connections, this also ensures that your database remains reliable even during periods of massive load. +In Hasura, you get automatic connection pools for your database connections. Apart from the general performance benefits +of using pooled connections, this also ensures that your database remains reliable even during periods of massive load. :::info Note @@ -32,10 +32,9 @@ Connection pooling is only available for [PostgreSQL](/api-reference/syntax-defs ::: -In Hasura Cloud, the connection pool is elastic i.e. shrinks and grows based on usage and also respects a configured max limit. -There are many other tunable parameters for the pool settings which can help you change the behaviour of the pool as required. -Read more about these in the [How connection pooling works](#how-connection-pooling-works) section below. - +In Hasura Cloud, the connection pool is elastic i.e. shrinks and grows based on usage and also respects a configured max +limit. There are many other tunable parameters for the pool settings which can help you change the behaviour of the pool +as required. Read more about these in the [How connection pooling works](#how-connection-pooling-works) section below. ### Getting started @@ -51,12 +50,12 @@ project can be calculated as `number of server instances * max_connections` ::: - + While adding a new database, under `Connection Settings`, set the desired `Total Max Connections` for primary and read -replica pools. To set or update `total_max_connections` for existing sources, head to the `Data > Databases > Manage > -[database-name] > Edit` page and scroll down to the `Connection Settings` section. +replica pools. To set or update `total_max_connections` for existing sources, head to the +`Data > Databases > Manage > [database-name] > Edit` page and scroll down to the `Connection Settings` section. @@ -156,17 +155,16 @@ X-Hasura-Role: admin - ## How connection pooling works -A connection pool starts off empty and as new requests arrive, a connection to the database is established. This connection -stays warm in the pool to be reused by any other waiting request. This ensures that subsequent requests do not have to -reestablish a database connection hence saving time and resources. - +A connection pool starts off empty and as new requests arrive, a connection to the database is established. This +connection stays warm in the pool to be reused by any other waiting request. This ensures that subsequent requests do +not have to reestablish a database connection hence saving time and resources. + After a certain period of connection idleness (specified by `idle_timeout`) or connection lifetime (specified by -`connection_lifetime`), the connection is released from the pool. This ensures that Hasura is not holding -connections which are not required. - +`connection_lifetime`), the connection is released from the pool. This ensures that Hasura is not holding connections +which are not required. + If the connection pool is saturated, then any new request waits for the pool to provide a connection. This ensures that your database is not bombarded with more connections than it can handle. You can also specify a `pool_timeout` to timeout any requests that are blocked on the connection pool. @@ -175,16 +173,16 @@ timeout any requests that are blocked on the connection pool. During heavy load, the number of connections may slightly exceed the `total_max_connections` limit for a brief period of time during which Hasura Cloud is trying to adjust pools in existing Hasura Server instances. Always set the -`total_max_connections` value slightly lower than the database true total maximum limit in order to avoid exceeding -your resource limits. +`total_max_connections` value slightly lower than the database true total maximum limit in order to avoid exceeding your +resource limits. ::: :::info `total_max_connections` and `max_connections` If both `total_max_connections` and `max_connections` are set, then `total_max_connections` will take precedence over -the `max_connections`. If neither is set, `total_max_connections` assumes a default value. If only `max_connections` -is set, then Hasura Cloud will not be able to maintain a fixed size of a pool and hence the total number of connections -on the database can be random. +the `max_connections`. If neither is set, `total_max_connections` assumes a default value. If only `max_connections` is +set, then Hasura Cloud will not be able to maintain a fixed size of a pool and hence the total number of connections on +the database can be random. ::: diff --git a/docs/docs/databases/connect-db/index.mdx b/docs/docs/databases/connect-db/index.mdx index ab260b18d65..cdc87cefd4c 100644 --- a/docs/docs/databases/connect-db/index.mdx +++ b/docs/docs/databases/connect-db/index.mdx @@ -26,7 +26,7 @@ based on the database schemas. In versions `v2.0.0` and above, databases can be connected and removed dynamically without having to restart the GraphQL engine instance via the console / metadata APIs / CLI: - + Head to `Data -> Manage -> Connect database` diff --git a/docs/docs/databases/connect-db/read-replicas.mdx b/docs/docs/databases/connect-db/read-replicas.mdx index 272bd856e6b..c358c1fa48c 100644 --- a/docs/docs/databases/connect-db/read-replicas.mdx +++ b/docs/docs/databases/connect-db/read-replicas.mdx @@ -32,7 +32,7 @@ mutations and metadata API calls to the primary. ### Postgres - + Head to `Data -> Manage -> -> Edit` @@ -140,7 +140,7 @@ supported for v2.0 and above projects.** ### MS SQL Server - + Head to `Data -> Manage -> -> Edit` diff --git a/docs/docs/deployment/deployment-guides/azure-container-instances-postgres.mdx b/docs/docs/deployment/deployment-guides/azure-container-instances-postgres.mdx index 6db09ce87b9..d6a370d089b 100644 --- a/docs/docs/deployment/deployment-guides/azure-container-instances-postgres.mdx +++ b/docs/docs/deployment/deployment-guides/azure-container-instances-postgres.mdx @@ -27,7 +27,7 @@ This guide walks you through deploying the Hasura GraphQL engine on [Azure](http You can deploy all the resources mentioned in this guide with the one-click button below. - + [![Deploy to Azure](https://aka.ms/deploytoazurebutton)](https://portal.azure.com/#create/Microsoft.Template/uri/https%3a%2f%2fraw.githubusercontent.com%2fhasura%2fgraphql-engine%2fstable%2finstall-manifests%2fazure-container-with-pg%2fazuredeploy.json) diff --git a/docs/docs/deployment/deployment-guides/docker.mdx b/docs/docs/deployment/deployment-guides/docker.mdx index 116343f7d21..7bf47dfbfa0 100644 --- a/docs/docs/deployment/deployment-guides/docker.mdx +++ b/docs/docs/deployment/deployment-guides/docker.mdx @@ -170,7 +170,7 @@ network config is different. This section shows how to connect in each of these ### Network config - +
diff --git a/docs/docs/deployment/health-checks/source-health-check.mdx b/docs/docs/deployment/health-checks/source-health-check.mdx index 216ca5bab0b..4ee06068775 100644 --- a/docs/docs/deployment/health-checks/source-health-check.mdx +++ b/docs/docs/deployment/health-checks/source-health-check.mdx @@ -27,15 +27,15 @@ Hasura enables users to check the health of connected data sources via the healt ## Configuring source health check -A health check configuration contains information that Hasura uses to determine the health state of a source. You -can set the time interval for when Hasura will re-perform the check on the source. +A health check configuration contains information that Hasura uses to determine the health state of a source. You can +set the time interval for when Hasura will re-perform the check on the source. Currently, Hasura supports enabling health checks on Postgres and MS SQL Server databases. Support for other data sources will be added soon. Health check configurations for Postgres and SQL Server sources are identical and are as follows. - + Console support will be added soon. @@ -114,10 +114,10 @@ X-Hasura-Role: admin ### API -Health check reports of sources can be obtained through a `GET` request from the -`/healthz/sources` API, on demand. Learn more about the API [here](/api-reference/source-health.mdx). +Health check reports of sources can be obtained through a `GET` request from the `/healthz/sources` API, on demand. +Learn more about the API [here](/api-reference/source-health.mdx). ### Logging -Hasura logs the health check status and other information via `health-check-log` type when enabled. -Learn more about the health checks logs [here](/deployment/logging.mdx#health-check-log-structure). +Hasura logs the health check status and other information via `health-check-log` type when enabled. Learn more about the +health checks logs [here](/deployment/logging.mdx#health-check-log-structure). diff --git a/docs/docs/event-triggers/clean-up/auto-cleanup.mdx b/docs/docs/event-triggers/clean-up/auto-cleanup.mdx index 28be1b5a475..7afbd569291 100644 --- a/docs/docs/event-triggers/clean-up/auto-cleanup.mdx +++ b/docs/docs/event-triggers/clean-up/auto-cleanup.mdx @@ -16,7 +16,7 @@ sidebar_class_name: cloud-and-enterprise-icon import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -import Thumbnail from "@site/src/components/Thumbnail"; +import Thumbnail from '@site/src/components/Thumbnail'; # Auto cleanup of event trigger logs @@ -32,26 +32,26 @@ Auto cleanup for event triggers is available from Hasura version `v2.13` and abo Hasura provides a way to automate the cleanup of the event trigger logs based on the following parameters: -| Name of the parameter | Description | Default | Example | -|-----------------------|-----------------------------------------------------------------------------------------------------------|---------|-------------------------------------------------------------------------------------------------------------------------------| -| clear_older_than | Minimum age (in hours) of the event logs that need to be cleared from when the cleanup action is invoked. | - | `clear_older_than: 168` means logs older than 168 hours (7 days) will be deleted. | -| schedule | Cron expression at which the cleanup should be invoked. | - | A `0 0 * * *` schedule means that the cleanup will be invoked every day at 00:00 (UTC time). | -| clean_invocation_logs | Option to indicate whether the corresponding invocation logs are also to be cleaned. | false | `clean_invocation_logs: false` means that invocation logs will not be cleaned. | -| batch_size | Maximum number of logs to delete in a single statement during the cleanup action. If there are more events to be cleaned than the `batch_size` then the cleanup action will execute multiple statements sequentially until all old event logs are cleared. | 10000 | Suppose there are 10000 events pending deletion and a `batch_size` of 1000 then the cleanup will be performed in 10 batches sequentially. | -| timeout | Maximum time (in seconds) that a batch can take during the cleanup process. If a batch times out, the cleanup process is halted. | 60 | A timeout of 60 means a batch of cleanup should not take more than 60 seconds. If a batch takes more than the `timeout`, then all the subsequent batches for the cleanup action will be cancelled. | -| paused | Indicates if the auto-cleanup process is paused. | false | `paused: true` means cleanup is paused, hence no logs will be deleted. | - +| Name of the parameter | Description | Default | Example | +| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| clear_older_than | Minimum age (in hours) of the event logs that need to be cleared from when the cleanup action is invoked. | - | `clear_older_than: 168` means logs older than 168 hours (7 days) will be deleted. | +| schedule | Cron expression at which the cleanup should be invoked. | - | A `0 0 * * *` schedule means that the cleanup will be invoked every day at 00:00 (UTC time). | +| clean_invocation_logs | Option to indicate whether the corresponding invocation logs are also to be cleaned. | false | `clean_invocation_logs: false` means that invocation logs will not be cleaned. | +| batch_size | Maximum number of logs to delete in a single statement during the cleanup action. If there are more events to be cleaned than the `batch_size` then the cleanup action will execute multiple statements sequentially until all old event logs are cleared. | 10000 | Suppose there are 10000 events pending deletion and a `batch_size` of 1000 then the cleanup will be performed in 10 batches sequentially. | +| timeout | Maximum time (in seconds) that a batch can take during the cleanup process. If a batch times out, the cleanup process is halted. | 60 | A timeout of 60 means a batch of cleanup should not take more than 60 seconds. If a batch takes more than the `timeout`, then all the subsequent batches for the cleanup action will be cancelled. | +| paused | Indicates if the auto-cleanup process is paused. | false | `paused: true` means cleanup is paused, hence no logs will be deleted. | ## Auto cleanup -For automatic cleanup, you can provide a cleanup config while [adding the event -trigger](/event-triggers/create-trigger.mdx) and Hasura will clean up the logs according to the provided config. +For automatic cleanup, you can provide a cleanup config while +[adding the event trigger](/event-triggers/create-trigger.mdx) and Hasura will clean up the logs according to the +provided config. - + -For an existing event trigger, head to the `Modify` tab of the event trigger and scroll down to the `Auto-cleanup Event -Logs` section. +For an existing event trigger, head to the `Modify` tab of the event trigger and scroll down to the +`Auto-cleanup Event Logs` section. @@ -126,11 +126,10 @@ X-Hasura-Role: admin - :::caution Warning -If you initially choose not to delete `invocation_logs`, but later they need to be deleted, you will need to delete - the retained logs manually. +If you initially choose not to delete `invocation_logs`, but later they need to be deleted, you will need to delete the +retained logs manually. ::: @@ -139,7 +138,6 @@ If you initially choose not to delete `invocation_logs`, but later they need to For cleaning up the event trigger logs using an API, Hasura provides the [cleanup_event_trigger_logs](/api-reference/metadata-api/event-triggers.mdx#metadata-cleanup-event-trigger-logs) API. - ## Managing automatic cleaners For the ease of managing automated cleanups, Hasura provides few metadata APIs such as: @@ -158,6 +156,7 @@ While applying migrations, you may pause all the installed cleaners for better p ### API usage examples - Activate the cleaners on all the triggers defined on all the event-trigger-supported sources + ```json POST /v1/metadata HTTP/1.1 Content-Type: application/json @@ -173,8 +172,8 @@ X-Hasura-Role: admin } ``` -- Activate the cleaners on all the triggers defined on the sources: `source_1`, - `source_2` +- Activate the cleaners on all the triggers defined on the sources: `source_1`, `source_2` + ```json POST /v1/metadata HTTP/1.1 Content-Type: application/json @@ -190,8 +189,8 @@ X-Hasura-Role: admin } ``` -- Activate the cleaners on triggers: `sample_trigger_1`, `sample_trigger_2` - defined on source `default` +- Activate the cleaners on triggers: `sample_trigger_1`, `sample_trigger_2` defined on source `default` + ```json POST /v1/metadata HTTP/1.1 Content-Type: application/json diff --git a/docs/docs/event-triggers/create-trigger.mdx b/docs/docs/event-triggers/create-trigger.mdx index 610cbfeea39..05161f86f0f 100644 --- a/docs/docs/event-triggers/create-trigger.mdx +++ b/docs/docs/event-triggers/create-trigger.mdx @@ -22,7 +22,7 @@ triggers exists for Postgres and MSSQL databases. ## Creating triggers - + Open the Hasura Console, head to the `Events` tab and click on the `Create` button to open the page below: @@ -138,7 +138,7 @@ Choose the columns here which you want the update operation to listen to. If a column is not selected here, then an update to that column will not trigger the webhook. - + Expand the `Advanced Settings` section on the Hasura Console to define advanced settings for an event trigger: @@ -240,7 +240,7 @@ Retry configuration is available in the "Advanced settings" when you create a tr 2. `interval_sec`: Number of seconds after which a failed invocation is retried. Default value is **10**. 3. `timeout_sec`: Number of seconds before which client closes the connection to the webhook. Default value is **60**. - + Expand the `Advanced Settings` section on the Hasura Console to define advanced settings for an event trigger: @@ -362,7 +362,7 @@ Each header has 3 parameters: variable in the GraphQL engine which will be resolved before sending the header. 3. `Value`: The value of the header. Either a static value or the name of an environment variable. - + Expand the `Advanced Settings` section on the Hasura Console to define advanced settings for an event trigger: diff --git a/docs/docs/event-triggers/invoke-trigger-manually.mdx b/docs/docs/event-triggers/invoke-trigger-manually.mdx index a8654e7c992..c54af5f520b 100644 --- a/docs/docs/event-triggers/invoke-trigger-manually.mdx +++ b/docs/docs/event-triggers/invoke-trigger-manually.mdx @@ -16,7 +16,7 @@ import Thumbnail from '@site/src/components/Thumbnail'; # Invoke event trigger manually - + You can select the `Via console` trigger operation while [creating an event trigger](/event-triggers/create-trigger.mdx) diff --git a/docs/docs/event-triggers/payload.mdx b/docs/docs/event-triggers/payload.mdx index aa828919e2a..f4baf83e2ce 100644 --- a/docs/docs/event-triggers/payload.mdx +++ b/docs/docs/event-triggers/payload.mdx @@ -8,8 +8,9 @@ keywords: - event trigger - payload --- -import Tabs from "@theme/Tabs"; -import TabItem from "@theme/TabItem"; + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; # Event trigger payload @@ -60,8 +61,7 @@ Content-Type: application/json | schema-name | String | Name of the schema for the table | | table-name | String | Name of the table | - - + **In case of**: @@ -77,8 +77,7 @@ Content-Type: application/json - `event.data.new` will be `null` - MANUAL - `event.data.old` will be `null` - - `event.data.new` will contain the current row - + - `event.data.new` will contain the current row :::info Note @@ -141,17 +140,15 @@ Content-Type: application/json - `event.data.new` will be `null` - MANUAL - `event.data.old` will be `null` - - `event.data.new` will contain the current row - + - `event.data.new` will contain the current row :::info Note -- In case of `UPDATE`, the events are delivered only if new data is - distinct from old data. We use the primary keys to join the temporary tables `inserted` - and `deleted` tables to correlate the old and new data. +- In case of `UPDATE`, the events are delivered only if new data is distinct from old data. We use the primary keys to + join the temporary tables `inserted` and `deleted` tables to correlate the old and new data. - `UPDATE` event triggers will only work on tables which have primary keys. -- Since we use the primary key to co-relate DELETED and INSERTED table, if the - primary key is updated then it is not possible to correlate the `old` and `new` data. Hence, only `new` data is sent in this case. +- Since we use the primary key to co-relate DELETED and INSERTED table, if the primary key is updated then it is not + possible to correlate the `old` and `new` data. Hence, only `new` data is sent in this case. ::: @@ -189,8 +186,6 @@ Content-Type: application/json - - ## Syntax definitions ### Object diff --git a/docs/docs/event-triggers/rest-connectors.mdx b/docs/docs/event-triggers/rest-connectors.mdx index 6187ae8a6e8..a6aab024298 100644 --- a/docs/docs/event-triggers/rest-connectors.mdx +++ b/docs/docs/event-triggers/rest-connectors.mdx @@ -43,7 +43,7 @@ REST Connectors are supported in Hasura GraphQL Engine versions `v2.1.0` and abo REST Connectors can be configured either when creating a new event trigger or editing an existing one. See the transform options [here](#event-trigger-transform-types): - + Go to the `Events` tab on the console and create or modify an event trigger. Scroll down to `Configure REST Connectors` @@ -199,7 +199,7 @@ You can transform your: You can change the request method to adapt to your API's expected format. - + Head to the `Events > [event_trigger_name]` page. Under `Configure REST Connectors` click on @@ -305,7 +305,7 @@ You can also provide query params to add to the URL. You can use the [Kriti templating language](/api-reference/kriti-templating.mdx) to construct any string values here. - + Head to the `Events > [event_trigger_name]` page. Under `Configure REST Connectors` click on @@ -442,7 +442,7 @@ request body to `x_www_form_urlencoded` formats. If you are using a `GET` request, you might want to not send any request body, and additionally not send a `content-type` header to the webhook. You can do that using the disable body feature. - + In the `Configure REST Connectors` section, click on `Add Request Options Transform`, and convert the `Request Method` @@ -550,7 +550,7 @@ X-Hasura-Role: admin You can transform Request Body to `application/json` format using the following steps: - + In the `Configure REST Connectors` section, click on `Add Payload Transform`. By default console sends the body as @@ -659,7 +659,7 @@ While doing `x_www_form_urlencoded` transformation, please note that as all chan when calling the API, so you will need to remove the default `application/json` header and add a `application/x-www-form-urlencoded` header. - + In the `Configure REST Connectors` section, click on `Add Payload Transform`. Change the dropdown next to diff --git a/docs/docs/hasura-cli/install-hasura-cli.mdx b/docs/docs/hasura-cli/install-hasura-cli.mdx index 2dd283457fa..dca8405d7ea 100644 --- a/docs/docs/hasura-cli/install-hasura-cli.mdx +++ b/docs/docs/hasura-cli/install-hasura-cli.mdx @@ -24,7 +24,7 @@ import Link from '@docusaurus/Link'; The recommended installation method of the Hasura CLI is to install it as a global binary. You can download it by following the instructions for your operating system: - + In your Linux shell, run the following command: diff --git a/docs/docs/migrations-metadata-seeds/legacy-configs/config-v2/manage-metadata.mdx b/docs/docs/migrations-metadata-seeds/legacy-configs/config-v2/manage-metadata.mdx index 19e13c72c72..54ab6c39208 100644 --- a/docs/docs/migrations-metadata-seeds/legacy-configs/config-v2/manage-metadata.mdx +++ b/docs/docs/migrations-metadata-seeds/legacy-configs/config-v2/manage-metadata.mdx @@ -19,14 +19,15 @@ import Thumbnail from '@site/src/components/Thumbnail'; If your Postgres schema is already managed with a tool like knex, TypeORM, Django/Rails migrations, you will still need a way to export the actions you performed on the Hasura console to apply it later on another Hasura instance. -All the actions performed on the console, like tracking tables/views/custom functions, creating relationships, configuring -permissions, creating event triggers and remote schemas, etc. can be exported as a JSON/yaml metadata file which can be -version controlled. The metadata file can be later imported to another Hasura instance to get the same configuration. -You can also manually edit the metadata file to add more objects to it and then use it to update the instance. +All the actions performed on the console, like tracking tables/views/custom functions, creating relationships, +configuring permissions, creating event triggers and remote schemas, etc. can be exported as a JSON/yaml metadata file +which can be version controlled. The metadata file can be later imported to another Hasura instance to get the same +configuration. You can also manually edit the metadata file to add more objects to it and then use it to update the +instance. ## Exporting Hasura metadata - + Metadata can be exported with the [hasura metadata export](/hasura-cli/commands/hasura_metadata_export.mdx) command. @@ -83,7 +84,7 @@ modified version of an instance's metadata onto itself. Importing completely replaces the metadata on that instance, i.e. you lose any metadata that was already present before. - + Metadata can be applied with the [hasura metadata apply](/hasura-cli/commands/hasura_metadata_apply.mdx) command. @@ -134,7 +135,7 @@ importing the metadata. In some cases, the metadata can be out of sync with the Postgres schema. For example, when a new column has been added to a table via an external tool such as `psql`. - + @@ -183,7 +184,7 @@ Resetting GraphQL engine's metadata is an irreversible process. It is recommende it can be reapplied if needed or else that information will be lost and Hasura will have to be configured again from scratch (e.g. tracking tables, relationships, creating triggers, actions, etc.). - + diff --git a/docs/docs/migrations-metadata-seeds/manage-metadata.mdx b/docs/docs/migrations-metadata-seeds/manage-metadata.mdx index bc6714de3c0..293b9cf5b6a 100644 --- a/docs/docs/migrations-metadata-seeds/manage-metadata.mdx +++ b/docs/docs/migrations-metadata-seeds/manage-metadata.mdx @@ -78,7 +78,7 @@ same. To export your Metadata means to save your internal Hasura Metadata configuration to a file or group of files in order to track it with version control or use it in a CI/CD pipeline. - + To export your entire Metadata using the Hasura CLI execute the following command in your terminal: @@ -125,11 +125,18 @@ This will export the Metadata as YAML files in the `/metadata` directory eg: 1. Click on the settings ⚙ icon at the top right corner of the console screen. - + 2. In the Hasura Metadata actions page that opens, click on the `Export Metadata` button. - + 3. This will prompt a file download for `hasura_metadata_[timestamp].json`. Save the JSON blob file. @@ -162,7 +169,7 @@ instance's Metadata onto itself to replace the existing Metadata. Applying or importing completely replaces the Metadata on that instance, i.e. you lose any Metadata that existed before applying. - + Metadata can be applied with the [hasura metadata apply](/hasura-cli/commands/hasura_metadata_apply.mdx) command. @@ -183,11 +190,18 @@ INFO Metadata applied 1. Click on the settings ⚙ icon at the top right corner of the console screen. - + 2. Click on `Import Metadata` button. - + 3. Choose a `hasura_metadata.json` file that was exported earlier. @@ -233,7 +247,7 @@ version control. In some cases, the Metadata can be out of sync with the database schema. For example, when a new column has been added to a table via an external tool such as `psql`. - + @@ -256,11 +270,18 @@ INFO Metadata is consistent 1. Click on the settings ⚙ icon at the top right corner of the console screen. - + 2. Click on `Reload` button. - + 3. A notification should appear indicating success. @@ -298,7 +319,7 @@ Clearing the Hasura Metadata is an irreversible process. It is highly recommende reapplied if necessary or else that information will be lost and Hasura will have to be configured again from scratch (e.g. tables tracking, relationships, triggers, actions, etc.). - + @@ -320,7 +341,10 @@ INFO Metadata cleared 1. Click on the settings ⚙ icon at the top right corner of the console screen. - + 2. Click on `Reset` button. @@ -354,7 +378,7 @@ If an admin secret is set, add `-H 'X-Hasura-Admin-Secret: [your-admin-secret]'` Metadata should always be consistent against the underlying database schemas. When it's not, Hasura will mark the Metadata objects as `inconsistent`. - + @@ -403,7 +427,10 @@ INFO all inconsistent objects removed from metadata 1. Click on the settings ⚙ icon at the top right corner of the console screen. - + 2. Click on `Reset` button. diff --git a/docs/docs/queries/ms-sql-server/performance.mdx b/docs/docs/queries/ms-sql-server/performance.mdx index 18d252f685a..192eb77c269 100644 --- a/docs/docs/queries/ms-sql-server/performance.mdx +++ b/docs/docs/queries/ms-sql-server/performance.mdx @@ -83,7 +83,7 @@ The following statement sets an index on `name` in the `authors` table. CREATE INDEX ON authors (name); ``` - + An index can be added in the `Data -> SQL` tab in the Hasura console. diff --git a/docs/docs/queries/postgres/performance.mdx b/docs/docs/queries/postgres/performance.mdx index 704a7a51cdf..ab70a21b622 100644 --- a/docs/docs/queries/postgres/performance.mdx +++ b/docs/docs/queries/postgres/performance.mdx @@ -82,7 +82,7 @@ The following statement sets an index on `name` in the `authors` table. CREATE INDEX ON authors (name); ``` - + An index can be added in the `Data -> SQL` tab in the Hasura console. diff --git a/docs/docs/remote-schemas/adding-schema.mdx b/docs/docs/remote-schemas/adding-schema.mdx index dad92ce8385..50b2d77feeb 100644 --- a/docs/docs/remote-schemas/adding-schema.mdx +++ b/docs/docs/remote-schemas/adding-schema.mdx @@ -49,7 +49,7 @@ The following details need to be specified for merging a remote schema: value. This environment variable needs to be present when you start the GraphQL engine. When Hasura sends requests to your remote server, it will pick up the value from this environment variable. - + Head to the `Remote Schemas` tab of the console and click on the `Add` button on the left sidebar. @@ -124,7 +124,7 @@ should be started with these environment variables. ## Step 2: Make queries to the remote server from Hasura - + Now you can head to the `API` tab and make queries to your remote server from Hasura. @@ -149,7 +149,7 @@ You can query your remote server by making requests to the Hasura GraphQL endpoi A remote server's GraphQL schema is cached and refreshed only when user explicitly reloads the remote schema. - + Head to `Remote Schemas -> [remote_schema_name] -> Details` and click the `Reload` button. diff --git a/docs/docs/remote-schemas/auth/remote-schema-permissions.mdx b/docs/docs/remote-schemas/auth/remote-schema-permissions.mdx index 559a8e306fc..9844fc6b630 100644 --- a/docs/docs/remote-schemas/auth/remote-schema-permissions.mdx +++ b/docs/docs/remote-schemas/auth/remote-schema-permissions.mdx @@ -282,7 +282,7 @@ Add a remote schema as described [here](/remote-schemas/adding-schema.mdx), if t ### Step 1: Set permissions - + - Head to the `Remote Schemas -> [remote-schema-name] -> Permissions` tab. diff --git a/docs/docs/remote-schemas/remote-relationships/remote-schema-db-relationships.mdx b/docs/docs/remote-schemas/remote-relationships/remote-schema-db-relationships.mdx index 119e005cee9..485c8e217a5 100644 --- a/docs/docs/remote-schemas/remote-relationships/remote-schema-db-relationships.mdx +++ b/docs/docs/remote-schemas/remote-relationships/remote-schema-db-relationships.mdx @@ -59,7 +59,7 @@ the remote schema and the `user` table of the source database. 3. We select `pg1` as the reference database, `public` as the reference schema and `user` as the reference table. 4. We select `user_id` as the source field and `id` as the reference column. - + - Head to the `Remote schema -> [remote-schema-name] -> Relationships` tab. diff --git a/docs/docs/remote-schemas/remote-relationships/remote-schema-relationships.mdx b/docs/docs/remote-schemas/remote-relationships/remote-schema-relationships.mdx index 5169d22a1c7..cfb66a50850 100644 --- a/docs/docs/remote-schemas/remote-relationships/remote-schema-relationships.mdx +++ b/docs/docs/remote-schemas/remote-relationships/remote-schema-relationships.mdx @@ -62,7 +62,7 @@ the `user` field of the second remote schema. 3. We select `user-remote-schema` as the reference remote schema. 4. We select `id` as the source field and `user_id` as the from field. - + - Head to the `Remote schema -> [remote-schema-name] -> Relationships` tab. diff --git a/docs/docs/scheduled-triggers/create-cron-trigger.mdx b/docs/docs/scheduled-triggers/create-cron-trigger.mdx index 409563c37c7..7aaddd40c3c 100644 --- a/docs/docs/scheduled-triggers/create-cron-trigger.mdx +++ b/docs/docs/scheduled-triggers/create-cron-trigger.mdx @@ -37,7 +37,7 @@ For example, we can create a cron trigger called `eod_reports`, to trigger the w the cron schedule `0 22 * * 1-5`, which means "At 22:00 on every day-of-week from Monday through Friday" (you can check this [here](https://crontab.guru/#0_22_*_*_1-5)). - + Navigate to `Events > Cron Triggers > Create` in your Hasura console. @@ -106,7 +106,7 @@ If you like, you can also define the following values: with it. - **Comment**: Custom description of the cron trigger. - + Expand the `Advanced` section. diff --git a/docs/docs/scheduled-triggers/create-one-off-scheduled-event.mdx b/docs/docs/scheduled-triggers/create-one-off-scheduled-event.mdx index 99614c8fe7b..9923fa4a82f 100644 --- a/docs/docs/scheduled-triggers/create-one-off-scheduled-event.mdx +++ b/docs/docs/scheduled-triggers/create-one-off-scheduled-event.mdx @@ -30,7 +30,7 @@ The following fields for required to define a scheduled event: - **Time**: The time to trigger the event. - **Payload**: The JSON payload which will be sent to the webhook. - + Navigate to `Events > One-off Scheduled Events > Schedule an event` in your Hasura console. @@ -82,7 +82,7 @@ If you like, you can also define advanced values: - **Retry configuration**: In case the call to the webhook fails. - **Comment**: Custom description of the scheduled trigger. - + Expand the `Advanced` section. diff --git a/docs/docs/schema/bigquery/computed-fields.mdx b/docs/docs/schema/bigquery/computed-fields.mdx index 5560fd6b312..d803d46debd 100644 --- a/docs/docs/schema/bigquery/computed-fields.mdx +++ b/docs/docs/schema/bigquery/computed-fields.mdx @@ -84,7 +84,7 @@ statement. ## Adding computed fields to a table {#bigquery-adding-computed-field} - + diff --git a/docs/docs/schema/bigquery/custom-field-names.mdx b/docs/docs/schema/bigquery/custom-field-names.mdx index d57708e729d..83d3c87cc12 100644 --- a/docs/docs/schema/bigquery/custom-field-names.mdx +++ b/docs/docs/schema/bigquery/custom-field-names.mdx @@ -30,7 +30,7 @@ This feature is supported in versions `v2.0.8` and later. ## Expose columns with a different name in the GraphQL API - + Console support coming soon @@ -102,7 +102,7 @@ A custom field name can be set for a column via the following 2 methods: ## Expose table root fields with a different name in the GraphQL API - + Console support coming soon diff --git a/docs/docs/schema/bigquery/data-validations.mdx b/docs/docs/schema/bigquery/data-validations.mdx index 4e3414248b4..20a3d286464 100644 --- a/docs/docs/schema/bigquery/data-validations.mdx +++ b/docs/docs/schema/bigquery/data-validations.mdx @@ -45,7 +45,7 @@ articles (id int, title text, author_id int, body text) Now, we can create a role `editor` and add a select validation rule as follows: - + @@ -142,8 +142,8 @@ authors (id int, name text) articles (id int, title text, author_id int, body text) ``` -Also, suppose there is an [object relationship](schema/bigquery/table-relationships/index.mdx) `articles.author` -defined as: +Also, suppose there is an [object relationship](schema/bigquery/table-relationships/index.mdx) `articles.author` defined +as: ```sql articles.author_id -> authors.id @@ -151,7 +151,7 @@ articles.author_id -> authors.id Now, we can create a role `author` and add an select validation rule as follows: - + diff --git a/docs/docs/schema/bigquery/remote-relationships/remote-schema-relationships.mdx b/docs/docs/schema/bigquery/remote-relationships/remote-schema-relationships.mdx index e035122e66f..62fb829ca14 100644 --- a/docs/docs/schema/bigquery/remote-relationships/remote-schema-relationships.mdx +++ b/docs/docs/schema/bigquery/remote-relationships/remote-schema-relationships.mdx @@ -68,7 +68,7 @@ schema `author-remote-schema`. 3. We set up the config to join the `id` input argument of our remote schema field to the `author_id` column of this table (in this case, the `articles` table). - + - Head to the `Data -> [table-name] -> Relationships` tab. diff --git a/docs/docs/schema/bigquery/remote-relationships/remote-source-relationships.mdx b/docs/docs/schema/bigquery/remote-relationships/remote-source-relationships.mdx index 507e663c13d..355055a8737 100644 --- a/docs/docs/schema/bigquery/remote-relationships/remote-source-relationships.mdx +++ b/docs/docs/schema/bigquery/remote-relationships/remote-source-relationships.mdx @@ -63,7 +63,7 @@ For example, say we have a table `articles(id int, author_id int)` in the source We can create an object remote database relationship `author` joining the `articles` table to the `author` table using the `articles.author_id` and `author.id` fields. - + Console support will be added soon. diff --git a/docs/docs/schema/bigquery/table-relationships/create.mdx b/docs/docs/schema/bigquery/table-relationships/create.mdx index 78b7e2e0fa9..a26aeaeba07 100644 --- a/docs/docs/schema/bigquery/table-relationships/create.mdx +++ b/docs/docs/schema/bigquery/table-relationships/create.mdx @@ -36,7 +36,7 @@ Let us now connect these tables to enable nested queries using manual relationsh Each article has one author. This is an `object relationship`. - + In the console, select the `articles` table and navigate to the `Relationships` tab, then click `Configure` under @@ -153,7 +153,7 @@ For each author, there are many possible related articles. If we wanted to estab would return an array. We model this in the Hasura console using an array relationship (we can also think of this as being a one-to-many relationship between authors and articles). - + In the console, select the `authors` table and navigate to the `Relationships` tab, then click `Configure` under diff --git a/docs/docs/schema/bigquery/table-relationships/rename.mdx b/docs/docs/schema/bigquery/table-relationships/rename.mdx index 744c8726d2d..41cb806092f 100644 --- a/docs/docs/schema/bigquery/table-relationships/rename.mdx +++ b/docs/docs/schema/bigquery/table-relationships/rename.mdx @@ -18,7 +18,7 @@ import TabItem from '@theme/TabItem'; An existing relationship can be renamed as follows: - + - Head to `Data -> [table-name] -> Relationships` in the console diff --git a/docs/docs/schema/bigquery/tables.mdx b/docs/docs/schema/bigquery/tables.mdx index e10602ebdce..80d7b54f40e 100644 --- a/docs/docs/schema/bigquery/tables.mdx +++ b/docs/docs/schema/bigquery/tables.mdx @@ -43,7 +43,7 @@ articles ( ``` - + Open the Hasura console and head to the `Data` tab and click on the button on the left side bar to open up an interface @@ -118,7 +118,7 @@ X-Hasura-Role: admin Tables can be present in the underlying BigQuery database without being exposed over the GraphQL API. In order to expose a table over the GraphQL API, it needs to be **tracked**. - + When a table is created via the Hasura console, it gets tracked by default. @@ -238,6 +238,7 @@ tab in the console. _(You may want to add some sample data into the tables first - Query all rows in the `articles` table: + {' '} + Console support coming soon @@ -104,7 +104,7 @@ A custom field name can be set for a column via the following 2 methods: ## Expose table root fields with a different name in the GraphQL API - + Console support coming soon diff --git a/docs/docs/schema/ms-sql-server/default-values/mssql-column-presets.mdx b/docs/docs/schema/ms-sql-server/default-values/mssql-column-presets.mdx index 13ea03afd0f..d2b37397ec7 100644 --- a/docs/docs/schema/ms-sql-server/default-values/mssql-column-presets.mdx +++ b/docs/docs/schema/ms-sql-server/default-values/mssql-column-presets.mdx @@ -37,7 +37,7 @@ of the user's session variable whenever a new row is added to the `article` tabl ## Step 1: Configure a column preset - + Support will be added soon. diff --git a/docs/docs/schema/ms-sql-server/default-values/mssql-defaults.mdx b/docs/docs/schema/ms-sql-server/default-values/mssql-defaults.mdx index 0fd419a04e7..9fe0992de34 100644 --- a/docs/docs/schema/ms-sql-server/default-values/mssql-defaults.mdx +++ b/docs/docs/schema/ms-sql-server/default-values/mssql-defaults.mdx @@ -37,7 +37,7 @@ whenever a new row is added to the table: Edit the `created_at` field and set its default value as the SQL function `GETDATE()`. - + Open the console and head to `Data -> [article] -> Modify`. diff --git a/docs/docs/schema/ms-sql-server/remote-relationships/remote-schema-relationships.mdx b/docs/docs/schema/ms-sql-server/remote-relationships/remote-schema-relationships.mdx index 0de1081c720..fb736e1621c 100644 --- a/docs/docs/schema/ms-sql-server/remote-relationships/remote-schema-relationships.mdx +++ b/docs/docs/schema/ms-sql-server/remote-relationships/remote-schema-relationships.mdx @@ -67,7 +67,7 @@ For example, let's assume that our database has a table `order(id int, user_id i 3. We set up the config to join the `id` input argument of our remote schema field to the `user_id` column of this table (in this case, the `order` table). - + - Head to the `Data -> [table-name] -> Relationships` tab. diff --git a/docs/docs/schema/ms-sql-server/remote-relationships/remote-source-relationships.mdx b/docs/docs/schema/ms-sql-server/remote-relationships/remote-source-relationships.mdx index 0a5b48e8b37..d730de89f11 100644 --- a/docs/docs/schema/ms-sql-server/remote-relationships/remote-source-relationships.mdx +++ b/docs/docs/schema/ms-sql-server/remote-relationships/remote-source-relationships.mdx @@ -62,7 +62,7 @@ For example, say we have a table `order(id int, user_id int)` in the source data We can create an object remote database relationship `user` joining the `order` table to the `user` table using the `order.user_id` and `user.id` fields. - + Head to the `Data > [database] > [orders] > Relationships` tab. Under the `Remote Database Relationships` section, diff --git a/docs/docs/schema/ms-sql-server/table-relationships/create.mdx b/docs/docs/schema/ms-sql-server/table-relationships/create.mdx index f430703e972..d8b8b5be2eb 100644 --- a/docs/docs/schema/ms-sql-server/table-relationships/create.mdx +++ b/docs/docs/schema/ms-sql-server/table-relationships/create.mdx @@ -37,7 +37,7 @@ Let us now connect these tables to enable nested queries using a foreign-key: Let's add a foreign-key constraint to the `author_id` column in the `articles` table. - + In the console, navigate to the `Modify` tab of the `articles` table. Click the `Add` button in the Foreign Keys section @@ -97,7 +97,7 @@ X-Hasura-Role: admin Each article has one author. This is an `object relationship`. - + The console infers potential relationships using the foreign-key created above and recommends these in the @@ -212,7 +212,7 @@ An author can write multiple articles. This is an `array relationship`. You can add an `array relationship` in the same fashion as an `object relationship` as shown above. - + On the console, add an `array relationship` named `articles` for the `authors` table as shown here: @@ -359,7 +359,7 @@ Let's say you have a table `authors (id, name)` and a [view](/schema/ms-sql-serv Let us now create an `object relationship` called `avg_rating` from the `authors` table to the `author_avg_rating` view using a manual relationship: - + **Step 1: Open the manual relationship section** @@ -498,7 +498,7 @@ Fetch a list of authors with the average rating of their articles: As mentioned in the Introduction section above, relationships can be inferred via foreign-keys that exist in your database: - + The console infers potential relationships using existing foreign-keys and recommends these on the `Data -> Schema` page diff --git a/docs/docs/schema/ms-sql-server/table-relationships/rename.mdx b/docs/docs/schema/ms-sql-server/table-relationships/rename.mdx index 53c76975862..0fc16b920a6 100644 --- a/docs/docs/schema/ms-sql-server/table-relationships/rename.mdx +++ b/docs/docs/schema/ms-sql-server/table-relationships/rename.mdx @@ -11,14 +11,14 @@ keywords: - rename --- -import Tabs from "@theme/Tabs"; -import TabItem from "@theme/TabItem"; +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; # MS SQL Server: Renaming Relationships An existing relationship can be renamed as follows: - + - Head to `Data -> [table-name] -> Relationships` in the console @@ -28,8 +28,8 @@ An existing relationship can be renamed as follows: -You can rename a relationship by changing the relationship name in the -`tables.yaml` file inside the `metadata` directory: +You can rename a relationship by changing the relationship name in the `tables.yaml` file inside the `metadata` +directory: ```yaml {5} - table: @@ -77,10 +77,8 @@ X-Hasura-Role: admin :::info Note -You might not be allowed to drop a relationship if it has been -referenced elsewhere (e.g. in a permissions rule). +You might not be allowed to drop a relationship if it has been referenced elsewhere (e.g. in a permissions rule). -In this case you will have to delete the references first, rename the -relationship, and then re-add the references. +In this case you will have to delete the references first, rename the relationship, and then re-add the references. ::: diff --git a/docs/docs/schema/ms-sql-server/tables.mdx b/docs/docs/schema/ms-sql-server/tables.mdx index 995594e3630..67aa96df23b 100644 --- a/docs/docs/schema/ms-sql-server/tables.mdx +++ b/docs/docs/schema/ms-sql-server/tables.mdx @@ -40,7 +40,7 @@ articles ( ) ``` - + Open the Hasura console and head to the `Data` tab and click on the button on the left side bar to open up an interface @@ -101,7 +101,7 @@ X-Hasura-Role: admin Tables can be present in the underlying MS SQL Server database without being exposed over the GraphQL API. In order to expose a table over the GraphQL API, it needs to be **tracked**. - + When a table is created via the Hasura console, it gets tracked by default. diff --git a/docs/docs/schema/ms-sql-server/using-existing-database.mdx b/docs/docs/schema/ms-sql-server/using-existing-database.mdx index e8818eca40d..77176e44005 100644 --- a/docs/docs/schema/ms-sql-server/using-existing-database.mdx +++ b/docs/docs/schema/ms-sql-server/using-existing-database.mdx @@ -28,7 +28,7 @@ Tracking a table or a view means telling Hasura GraphQL engine that you want to ### To track a table or a view - + 1. Head to the `Data -> Schema` section of the console. @@ -78,7 +78,7 @@ X-Hasura-Role: admin ### To track all tables and views present in the database - + 1. Head to the `Data -> Schema` section of the console. @@ -153,7 +153,7 @@ tables involved in the foreign-key. ### To track a foreign-key between two tables in the database - + 1. Head to the `Data -> Schema` section of the console. @@ -262,7 +262,7 @@ X-Hasura-Role: admin ### To track all the foreign-keys of all tables in the database - + 1. Head to the `Data -> Schema` section of the console. diff --git a/docs/docs/schema/ms-sql-server/views.mdx b/docs/docs/schema/ms-sql-server/views.mdx index 2a1f47bd23b..d3ede32cf6c 100644 --- a/docs/docs/schema/ms-sql-server/views.mdx +++ b/docs/docs/schema/ms-sql-server/views.mdx @@ -26,7 +26,7 @@ Hasura GraphQL engine lets you expose views over the GraphQL API to allow queryi ## Creating views {#ms-sql-server-create-views} - + Views can be created using SQL which can be run in the Hasura console: @@ -77,7 +77,7 @@ X-Hasura-Role: admin Views can be present in the underlying MS SQL Server database without being exposed over the GraphQL API. In order to expose a view over the GraphQL API, it needs to be **tracked**. - + While creating views from the `Data -> SQL` page, selecting the `Track this` checkbox will expose the new view over the diff --git a/docs/docs/schema/postgres/computed-fields.mdx b/docs/docs/schema/postgres/computed-fields.mdx index c708f20d44a..677fcf9f82e 100644 --- a/docs/docs/schema/postgres/computed-fields.mdx +++ b/docs/docs/schema/postgres/computed-fields.mdx @@ -177,7 +177,7 @@ Query data from the `authors` table: ## Adding a computed field to a table/view {#pg-adding-computed-field} - + Head to the `Modify` tab of the table/view and click on the `Add` button in the `Computed fields` section: diff --git a/docs/docs/schema/postgres/custom-field-names.mdx b/docs/docs/schema/postgres/custom-field-names.mdx index 4e72bcf2bac..9c7b3075875 100644 --- a/docs/docs/schema/postgres/custom-field-names.mdx +++ b/docs/docs/schema/postgres/custom-field-names.mdx @@ -31,7 +31,7 @@ This feature is supported in versions `v1.0.0-beta.8` and later. ## Expose columns with a different name in the GraphQL API - + Head to the `Data -> [table-name] -> Modify`. On the relevant field, click `Edit` and change the GraphQL field name to a @@ -118,7 +118,7 @@ A custom field name can be set for a column via the following 2 methods: ## Expose table root fields with a different name in the GraphQL API - + Head to the `Data -> [table-name] -> Modify`. Click the `Edit` button in the `Custom GraphQL Root Fields` section and diff --git a/docs/docs/schema/postgres/custom-functions.mdx b/docs/docs/schema/postgres/custom-functions.mdx index 8d09312e681..3cadd960734 100644 --- a/docs/docs/schema/postgres/custom-functions.mdx +++ b/docs/docs/schema/postgres/custom-functions.mdx @@ -47,7 +47,7 @@ Currently, only functions which satisfy the following constraints can be exposed SQL functions can be created using SQL statements which can be executed as follows: - + - Head to the `Data -> SQL` section of the Hasura console @@ -96,7 +96,7 @@ X-Hasura-Role: admin Functions can be present in the underlying Postgres database without being exposed over the GraphQL API. In order to expose a function over the GraphQL API, it needs to be **tracked**. - + While creating functions from the `Data -> SQL` page, selecting the `Track this` checkbox will expose the new function diff --git a/docs/docs/schema/postgres/data-validations.mdx b/docs/docs/schema/postgres/data-validations.mdx index 589a102b471..fb2e244b19d 100644 --- a/docs/docs/schema/postgres/data-validations.mdx +++ b/docs/docs/schema/postgres/data-validations.mdx @@ -48,7 +48,7 @@ author (id uuid, name text, rating integer) We can now add a check constraint to limit the `rating` values as follows: - + Head to the `Modify` tab in the table page and add a check constraint in the `Check Constraints` section: @@ -146,7 +146,7 @@ an article's content exceeds a certain number of words, and then add a [Postgres trigger](https://www.postgresql.org/docs/current/sql-createtrigger.html) that will call this function every time before an article is inserted or updated. - + - Head to the `Data -> SQL` section of the Hasura console @@ -265,7 +265,7 @@ article (id uuid, title text, content text, author_id uuid) Now, we can create a role `user` and add an insert validation rule as follows: - + @@ -369,7 +369,7 @@ article.author_id -> author.id Now, we can create a role `user` and add an insert validation rule as follows: - + + The column preset option is available under the `Permissions` tab of a table. Open the console and head to diff --git a/docs/docs/schema/postgres/default-values/created-updated-timestamps.mdx b/docs/docs/schema/postgres/default-values/created-updated-timestamps.mdx index bc76e4e327e..0b072e69970 100644 --- a/docs/docs/schema/postgres/default-values/created-updated-timestamps.mdx +++ b/docs/docs/schema/postgres/default-values/created-updated-timestamps.mdx @@ -24,7 +24,7 @@ created or last updated. This page explains how to add these. ## Add a created_at timestamp - + On the Hasura console, click on the `Modify` tab of a table. When clicking on the `+Frequently used columns` button, @@ -83,7 +83,7 @@ X-Hasura-Role: admin ## Add an updated_at timestamp - + On the Hasura console, click on the `Modify` tab of a table. When clicking on the `+Frequently used columns` button, diff --git a/docs/docs/schema/postgres/default-values/postgres-defaults.mdx b/docs/docs/schema/postgres/default-values/postgres-defaults.mdx index 90eb1817a73..f7fd49865f1 100644 --- a/docs/docs/schema/postgres/default-values/postgres-defaults.mdx +++ b/docs/docs/schema/postgres/default-values/postgres-defaults.mdx @@ -37,7 +37,7 @@ whenever a new row is added to the table: Edit the `created_at` field and set its default value as the SQL function `now()`. - + Open the console and head to `Data -> [article] -> Modify`. diff --git a/docs/docs/schema/postgres/default-values/sql-functions.mdx b/docs/docs/schema/postgres/default-values/sql-functions.mdx index a4f0605e7c9..6746d0393bd 100644 --- a/docs/docs/schema/postgres/default-values/sql-functions.mdx +++ b/docs/docs/schema/postgres/default-values/sql-functions.mdx @@ -48,7 +48,7 @@ value of the `output` column as the uppercased value of the string received in t Modify the table `sql_function_table` and make its `output` column nullable. - + Open the console and head to `Data -> [sql_function_table] -> Modify`: @@ -117,7 +117,7 @@ CREATE FUNCTION test_func() RETURNS trigger AS $emp_stamp$ FOR EACH ROW EXECUTE PROCEDURE test_func(); ``` - + Head to `Data -> SQL` and run the above SQL: diff --git a/docs/docs/schema/postgres/enums.mdx b/docs/docs/schema/postgres/enums.mdx index 11d55e37c81..7e4438273b9 100644 --- a/docs/docs/schema/postgres/enums.mdx +++ b/docs/docs/schema/postgres/enums.mdx @@ -130,7 +130,7 @@ Next, we need to tell Hasura that this table represents an enum. Once we have a table which satisfies the conditions for an enum table as described [above](#pg-create-enum-table), we need to tell Hasura that this table represents an enum. - + Head to the `Data -> [table-name] -> Modify` tab in the console and toggle the switch in the `Set table as enum` diff --git a/docs/docs/schema/postgres/naming-convention.mdx b/docs/docs/schema/postgres/naming-convention.mdx index 4ce6ea39a90..c10655de6bf 100644 --- a/docs/docs/schema/postgres/naming-convention.mdx +++ b/docs/docs/schema/postgres/naming-convention.mdx @@ -153,8 +153,9 @@ For the above schema, a sample GraphQL query will look like the following with t :::tip Behaviour of custom table name -For the `graphql-default` naming convention and a [custom table name](/api-reference/syntax-defs.mdx#table-config) for a given -table/view, the following rules are followed: +For the `graphql-default` naming convention and a [custom table name](/api-reference/syntax-defs.mdx#table-config) for a +given table/view, the following rules are followed: + - The custom table name will not be modified (change of case) if it is the first entity for a given name. - The custom table name may be modified if the name is being prefixed by something. @@ -175,13 +176,13 @@ This means any database source will follow this naming convention unless explici ## Set naming convention for a particular source {#pg-source-naming-convention} - + -Currently setting the database naming convention is only allowed at the time of connecting your database. +Currently setting the database naming convention is only allowed at the time of connecting your database. -Head to the `Data -> Manage -> Connect Database` page. Under the `GraphQL Field Customization` section after, enabling the naming -conventions, you can choose the naming convention of your choice. +Head to the `Data -> Manage -> Connect Database` page. Under the `GraphQL Field Customization` section after, enabling +the naming conventions, you can choose the naming convention of your choice. diff --git a/docs/docs/schema/postgres/remote-relationships/action-relationships.mdx b/docs/docs/schema/postgres/remote-relationships/action-relationships.mdx index 2e8a39c70fb..3c9b95f25a9 100644 --- a/docs/docs/schema/postgres/remote-relationships/action-relationships.mdx +++ b/docs/docs/schema/postgres/remote-relationships/action-relationships.mdx @@ -47,7 +47,7 @@ The following values can be defined for an action relationship: In this example, we're creating a relationship for the `createUser` action. We're creating a relationship called `user`, from the `id` field returned in the action response, to the `id` column of the `users` table. - + - Head to the `Actions -> [action-name] -> Relationships` tab. diff --git a/docs/docs/schema/postgres/remote-relationships/remote-schema-relationships.mdx b/docs/docs/schema/postgres/remote-relationships/remote-schema-relationships.mdx index e2dc18ee730..8fdf62608b4 100644 --- a/docs/docs/schema/postgres/remote-relationships/remote-schema-relationships.mdx +++ b/docs/docs/schema/postgres/remote-relationships/remote-schema-relationships.mdx @@ -67,7 +67,7 @@ For example, let's assume that our database has a table `order(id int, user_id i 3. We set up the config to join the `id` input argument of our remote schema field to the `user_id` column of this table (in this case, the `order` table). - + - Head to the `Data -> [table-name] -> Relationships` tab. diff --git a/docs/docs/schema/postgres/remote-relationships/remote-source-relationships.mdx b/docs/docs/schema/postgres/remote-relationships/remote-source-relationships.mdx index 3474db328c5..7c707552e77 100644 --- a/docs/docs/schema/postgres/remote-relationships/remote-source-relationships.mdx +++ b/docs/docs/schema/postgres/remote-relationships/remote-source-relationships.mdx @@ -62,7 +62,7 @@ For example, say we have a table `order(id int, user_id int)` in the source data We can create an object remote database relationship `user` joining the `order` table to the `user` table using the `order.user_id` and `user.id` fields. - + Head to the `Data > [database] > [orders] > Relationships` tab. Under the `Remote Database Relationships` section, diff --git a/docs/docs/schema/postgres/table-relationships/create.mdx b/docs/docs/schema/postgres/table-relationships/create.mdx index 8a9b8eb1242..d89e6d74b34 100644 --- a/docs/docs/schema/postgres/table-relationships/create.mdx +++ b/docs/docs/schema/postgres/table-relationships/create.mdx @@ -37,7 +37,7 @@ Let us now connect these tables to enable nested queries using a foreign-key: Let's add a foreign-key constraint to the `author_id` column in the `articles` table. - + In the console, navigate to the `Modify` tab of the `articles` table. Click the `Add` button in the Foreign Keys section @@ -97,7 +97,7 @@ X-Hasura-Role: admin Each article has one author. This is an `object relationship`. - + The console infers potential relationships using the foreign-key created above and recommends these in the @@ -212,7 +212,7 @@ An author can write multiple articles. This is an `array relationship`. You can add an `array relationship` in the same fashion as an `object relationship` as shown above. - + On the console, add an `array relationship` named `articles` for the `authors` table as shown here: @@ -359,7 +359,7 @@ which has the average rating of articles for each author. Let us now create an `object relationship` called `avg_rating` from the `authors` table to the `author_avg_rating` view using a manual relationship: - + **Step 1: Open the manual relationship section** @@ -498,7 +498,7 @@ Fetch a list of authors with the average rating of their articles: As mentioned in the Introduction section above, relationships can be inferred via foreign-keys that exist in your database: - + The console infers potential relationships using existing foreign-keys and recommends these on the `Data -> Schema` page diff --git a/docs/docs/schema/postgres/table-relationships/rename.mdx b/docs/docs/schema/postgres/table-relationships/rename.mdx index 5fb83c22a4b..dbff3b99c82 100644 --- a/docs/docs/schema/postgres/table-relationships/rename.mdx +++ b/docs/docs/schema/postgres/table-relationships/rename.mdx @@ -18,27 +18,27 @@ import TabItem from '@theme/TabItem'; An existing relationship can be renamed as follows: - + -- Head to `Data -> [table-name] -> Relationships` in the console -- Drop the existing relationship -- Recreate the relationship with the new name +- Head to `Data -> [table-name] -> Relationships` in the console +- Drop the existing relationship +- Recreate the relationship with the new name -You can rename a relationship by changing the relationship name in the -`tables.yaml` file inside the `metadata` directory: +You can rename a relationship by changing the relationship name in the `tables.yaml` file inside the `metadata` +directory: ```yaml {5} - table: schema: public name: articles object_relationships: - - name: author - using: - foreign_key_constraint_on: author_id + - name: author + using: + foreign_key_constraint_on: author_id - table: schema: public name: authors @@ -77,10 +77,8 @@ X-Hasura-Role: admin :::info Note -You might not be allowed to drop a relationship if it has been -referenced elsewhere (e.g. in a permissions rule). +You might not be allowed to drop a relationship if it has been referenced elsewhere (e.g. in a permissions rule). -In this case you will have to delete the references first, rename the -relationship, and then re-add the references. +In this case you will have to delete the references first, rename the relationship, and then re-add the references. ::: diff --git a/docs/docs/schema/postgres/tables.mdx b/docs/docs/schema/postgres/tables.mdx index 88c729defc0..9584f556970 100644 --- a/docs/docs/schema/postgres/tables.mdx +++ b/docs/docs/schema/postgres/tables.mdx @@ -40,7 +40,7 @@ articles ( ) ``` - + Open the Hasura console and head to the `Data` tab and click on the button on the left side bar to open up an interface @@ -101,7 +101,7 @@ X-Hasura-Role: admin Tables can be present in the underlying Postgres database without being exposed over the GraphQL API. In order to expose a table over the GraphQL API, it needs to be **tracked**. - + When a table is created via the Hasura console, it gets tracked by default. @@ -228,42 +228,43 @@ tab in the console. _(You may want to add some sample data into the tables first - Insert data in the `author` table: + {' '} + 1. Head to the `Data -> Schema` section of the console. @@ -78,7 +78,7 @@ X-Hasura-Role: admin ### To track all tables and views present in the database - + 1. Head to the `Data -> Schema` section of the console. @@ -153,7 +153,7 @@ tables involved in the foreign-key. ### To track a foreign-key between two tables in the database - + 1. Head to the `Data -> Schema` section of the console. @@ -262,7 +262,7 @@ X-Hasura-Role: admin ### To track all the foreign-keys of all tables in the database - + 1. Head to the `Data -> Schema` section of the console. diff --git a/docs/docs/schema/postgres/views.mdx b/docs/docs/schema/postgres/views.mdx index 8c65b80bdf6..9f8b3a8dcec 100644 --- a/docs/docs/schema/postgres/views.mdx +++ b/docs/docs/schema/postgres/views.mdx @@ -26,7 +26,7 @@ Hasura GraphQL engine lets you expose views over the GraphQL API to allow queryi ## Creating views {#pg-create-views} - + Views can be created using SQL which can be run in the Hasura console: @@ -75,7 +75,7 @@ X-Hasura-Role: admin Views can be present in the underlying Postgres database without being exposed over the GraphQL API. In order to expose a view over the GraphQL API, it needs to be **tracked**. - + While creating views from the `Data -> SQL` page, selecting the `Track this` checkbox will expose the new view over the diff --git a/docs/docs/security/allow-list.mdx b/docs/docs/security/allow-list.mdx index 48d64dbee5f..526a4aba6d8 100644 --- a/docs/docs/security/allow-list.mdx +++ b/docs/docs/security/allow-list.mdx @@ -9,10 +9,10 @@ keywords: sidebar_position: 8 --- -import Tabs from "@theme/Tabs"; -import TabItem from "@theme/TabItem"; -import Thumbnail from "@site/src/components/Thumbnail"; -import HeadingIcon from "@site/src/components/HeadingIcon"; +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; +import Thumbnail from '@site/src/components/Thumbnail'; +import HeadingIcon from '@site/src/components/HeadingIcon'; # Allow List of operations @@ -38,14 +38,11 @@ Allow-list validation will not be enforced for the `admin` role. Head to the `API` tab and find the `Allow List` section in the console. - + ## Adding or removing an operation in Allow List - + Head to the `API` tab and find the `Allow List` section in the console. @@ -67,16 +64,13 @@ query ($id: Int!) { After writing your query or selecting a query from quick add dropdown menu, click `Add Operation`. - + - **Upload File**: Alternatively, you can upload files, like this [sample file](https://gist.github.com/dsandip/8b1b4aa87708289d4c9f8fd9621eb025), to add multiple operations to the Allow List. Each operation in the file will need a unique name. Once you've selected your file, click `Add Operation`. - + @@ -159,25 +153,22 @@ A role-based Allow List is useful when you would like a query collection(s) to b :::info Note -Server support for Role-based Allow Lists in Cloud/Enterprise products is available from version `v2.3` and console support is available from version `v2.13`. In OSS, role-based entries are -ignored. +Server support for Role-based Allow Lists in Cloud/Enterprise products is available from version `v2.3` and console +support is available from version `v2.13`. In OSS, role-based entries are ignored. On older versions (which do not support role-based Allow Lists), any role-based Allow List Metadata entry will be treated as global. Hence, caution is advised when using role-based Allow List Metadata with older versions. ::: - + Head to the `API` tab and find the `Allow List` section on the Console. On the left side bar, you can see a list of query collections. After selecting a query collection, you can enable the roles which should have access to any query collection via the `Permissions` tab. - + @@ -229,17 +220,14 @@ Metadata API. ## Quick-create allowed operations -
Available on: Cloud
+
Available on: Cloud
### Hasura Cloud This feature lets you add to the Allow List with one click from the record of past operations. (With Hasura GraphQL Engine CE, Allow Lists must be managed manually). - + ## Recommended usage diff --git a/docs/src/css/custom.scss b/docs/src/css/custom.scss index e47b576451c..8f8ba288f6b 100644 --- a/docs/src/css/custom.scss +++ b/docs/src/css/custom.scss @@ -3,16 +3,16 @@ * bundles Infima by default. Infima is a CSS framework designed to * work well for content-centric websites. */ -@use "default-fonts-and-colors"; -@use "cloud-and-enterprise-menu-icons"; -@use "header"; -@use "sidebar"; -@use "table-of-contents"; -@use "doc"; -@use "footer"; -@use "introduction-page"; -@use "cloud-db-icon-gallery"; -@use "admonitions"; +@use 'default-fonts-and-colors'; +@use 'cloud-and-enterprise-menu-icons'; +@use 'header'; +@use 'sidebar'; +@use 'table-of-contents'; +@use 'doc'; +@use 'footer'; +@use 'introduction-page'; +@use 'cloud-db-icon-gallery'; +@use 'admonitions'; /* Custom Styles */ .no-shadow { @@ -24,7 +24,6 @@ opacity: 0.75; } - .sub-heading { grid-column: 1 / -1; @@ -55,7 +54,6 @@ tbody { /* Dark Mode Styles */ html[data-theme='dark'] { - .no-shadow { background-color: var(--color-gray-0); } diff --git a/docs/src/css/doc.scss b/docs/src/css/doc.scss index 8e0034e9cea..f7cc2650854 100644 --- a/docs/src/css/doc.scss +++ b/docs/src/css/doc.scss @@ -37,7 +37,6 @@ pre code { background-color: var(--ifm-code-background); } - .prism-code code { background-color: var(--color-gray-4); .theme-code-block-highlighted-line { @@ -60,7 +59,6 @@ html[data-theme='dark'] { } } - .theme-edit-this-page { display: flex; align-items: center; @@ -181,8 +179,9 @@ html[data-theme='dark'] { } } - &:first-child .pagination-nav__label::before, &--next .pagination-nav__label::after { - background: url("/icons/arrow_right-light.svg") no-repeat; + &:first-child .pagination-nav__label::before, + &--next .pagination-nav__label::after { + background: url('/icons/arrow_right-light.svg') no-repeat; } .pagination-nav__label { @@ -192,7 +191,8 @@ html[data-theme='dark'] { } .theme-edit-this-page { - &::before, &::after { + &::before, + &::after { filter: invert(1); } @@ -202,4 +202,19 @@ html[data-theme='dark'] { color: var(--ifm-color-gray-0); } } + + .tabs-container { + background: var(--color-gray-82); + code { + background: var(--color-gray-74); + } + } +} + +// Tabs styling +.tabs-container { + padding: 0 1rem; + padding-bottom: 1rem; + border-radius: 0.5rem; + box-shadow: var(--ifm-global-shadow-lw); }