Description

Support tracking functions as mutations (top-level fields under mutation root field). Support is added to the v2 API while remaining backwards compatible. See comments for API design decisions.

This is the second version of this feature implemented. The first is at: #5858

• new field (replacing as_mutation): expose_as: query or expose_as: mutation
  • if included we'll place the function where requested, regardless of its volatility
  • ...with the exception that non-volatile functions requested exposed as mutations will raise an error, since this probably indicates a mistake either in choice of function, or when defining the function
  • we'll raise a warning in some way whenever the volatility and expose_as are "mismatched" UPDATE: I punted on this
• if that field is omitted, we'll infer expose_as from the volatility (VOLATILE implies mutation, otherwise query)

Changelog

• CHANGELOG.md is updated with user-facing content relevant to this PR. If no changelog is required, then add the no-changelog-required label.

Affected components

• Server
• Console
• CLI
• Docs
• Community Content
• Build System
• Tests
• Other (list it)

Related Issues

#1514

Solution and Design

I re-used the machinery from support for tracking functions as queries and tried to do as little as possible.

Steps to test and verify

The tests written here represent the extent that I've tested/tried this out, so you can run those.

Limitations, known bugs & workarounds

The tests aren't particularly thorough; since so much of the queries code is re-used this seems all right to me.

Aggregations on the result set isn't implemented; it might be as simple as uncommenting the relevant line (I just noticed this as an unresolved question).

Server checklist

Catalog upgrade

Does this PR change Hasura Catalog version?

• No
• Yes
  • Updated docs with SQL for downgrading the catalog

Metadata

Does this PR add a new Metadata feature?

• No
• Yes
  • Does run_sql auto manages the new metadata through schema diffing?
    • Yes
    • Not required
  • Does run_sql auto manages the definitions of metadata on renaming?
    • Yes
    • Not required
  • Does export_metadata/replace_metadata supports the new metadata added?
    • Yes
    • Not required

GraphQL

• No new GraphQL schema is generated
• New GraphQL schema is being generated:
  • New types and typenames are correlated

Breaking changes

• No Breaking changes

• There are breaking changes:

  1. Metadata API

     Existing query types:

     • Modify args payload which is not backward compatible
     • Behavioural change of the API
     • Change in response JSON schema
     • Change in error code

  2. GraphQL API

     Schema Generation:

     • Change in any NamedType
     • Change in table field names

     Schema Resolve:-

     • Change in treatment of null value for any input fields

  3. Logging

     • Log JSON schema has changed
     • Log type names have changed