Schema/Metadata API Reference: Custom Functions¶
Table of contents
Introduction¶
Track/untrack a custom SQL function in the Hasura GraphQL engine.
Only tracked custom functions are available for querying/mutating/subscribing data over the GraphQL API.
track_function¶
track_function
is used to add a custom SQL function to the query
root field of the GraphQL schema.
Also refer a note here.
Add an SQL function search_articles
:
POST /v1/query HTTP/1.1
Content-Type: application/json
X-Hasura-Role: admin
{
"type": "track_function",
"args": {
"schema": "public",
"name": "search_articles"
}
}
track_function v2¶
Version 2 of track_function
is used to add a custom SQL function to the GraphQL schema.
It supports more configuration options than v1, and also supports tracking
functions as mutations.
Also refer a note here.
Track an SQL function called search_articles
with a Hasura session argument:
POST /v1/query HTTP/1.1
Content-Type: application/json
X-Hasura-Role: admin
{
"type": "track_function",
"version": 2,
"args": {
"function": {
"schema": "public",
"name": "search_articles"
},
"configuration": {
"session_argument": "hasura_session"
}
}
}
Track VOLATILE
SQL function reset_widget
as a mutation, so it appears
as a top-level field under the mutation
root field:
POST /v1/query HTTP/1.1
Content-Type: application/json
X-Hasura-Role: admin
{
"type": "track_function",
"version": 2,
"args": {
"function": {
"schema": "public",
"name": "reset_widget"
},
"configuration": {
"exposed_as": "mutation"
}
}
}
If exposed_as
is omitted, the location in the schema to expose the function
will be inferred from the function’s volatility, with VOLATILE
functions
appearing under the mutation
root, and others ending up under
query/subscription
.
In most cases you will want VOLATILE
functions to only be exposed as
mutations, and only STABLE
and IMMUTABLE
functions to be queries.
When tracking VOLATILE
functions under the query
root, the user needs
to guarantee that the field is idempotent and side-effect free, in the context
of the resulting GraphQL API.
One such use case might be a function that wraps a simple query and performs some logging visible only to administrators.
Note
It’s easy to accidentally give an SQL function the wrong volatility (or for a
function to end up with VOLATILE
mistakenly, since it’s the default).
Args syntax¶
Key | Required | Schema | Description |
---|---|---|---|
function | true | FunctionName | Name of the SQL function |
configuration | false | Function Configuration | Configuration for the SQL function |
Function Configuration¶
Key | Required | Schema | Description |
---|---|---|---|
session_argument | false | String | Function argument which accepts session info JSON |
exposed_as | false | String | In which part of the schema should we expose this function? Either “mutation” or “query”. |
Note
Currently, only functions which satisfy the following constraints can be exposed over the GraphQL API (terminology from Postgres docs):
- Function behaviour:
STABLE
orIMMUTABLE
functions may only be exposed as queries (i.e. withexposed_as: query
) - Return type: MUST be
SETOF <table-name>
OR<table_name>
where<table-name>
is already tracked - Argument modes: ONLY
IN
untrack_function¶
untrack_function
is used to remove a SQL function from the GraphQL schema.
Remove an SQL function search_articles
:
POST /v1/query HTTP/1.1
Content-Type: application/json
X-Hasura-Role: admin
{
"type": "untrack_function",
"args": {
"schema": "public",
"name": "search_articles"
}
}
Args syntax¶
Key | Required | Schema | Description |
---|---|---|---|
table | true | FunctionName | Name of the SQL function |