Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support tracking VOLATILE SQL functions as mutations. Closes #1514 #5858

Closed

Conversation

jberryman
Copy link
Collaborator

@jberryman jberryman commented Sep 29, 2020

Description

Support tracking VOLATILE 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.

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

@netlify
Copy link

netlify bot commented Sep 29, 2020

Deploy preview for hasura-docs ready!

Built with commit 4945ace

https://deploy-preview-5858--hasura-docs.netlify.app

@jberryman jberryman force-pushed the 1514-sql-function-mutations branch from 164b021 to f5a57e9 Compare October 3, 2020 22:41
@srghma
Copy link

srghma commented Oct 18, 2020

Heterogeneous execution was merged #5869

@jberryman jberryman force-pushed the 1514-sql-function-mutations branch 3 times, most recently from 0137bc9 to 0ba38d0 Compare October 28, 2020 15:28
@jberryman jberryman marked this pull request as ready for review October 28, 2020 16:10
@jberryman jberryman requested review from a team as code owners October 28, 2020 16:10
@jberryman jberryman force-pushed the 1514-sql-function-mutations branch from 0ba38d0 to 731bead Compare October 28, 2020 16:37
@jberryman jberryman requested review from abooij and rakeshkky October 28, 2020 16:50
@jberryman jberryman changed the title WIP Support tracking VOLATILE SQL functions as mutations. Closes #1514 Oct 28, 2020
server/src-lib/Hasura/GraphQL/Schema.hs Show resolved Hide resolved
server/src-lib/Hasura/RQL/DDL/Schema/Function.hs Outdated Show resolved Hide resolved
server/src-lib/Hasura/RQL/DDL/Schema/Function.hs Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
docs/graphql/core/schema/custom-functions.rst Outdated Show resolved Hide resolved
Comment on lines 298 to 301
-- | A pared-down version of 'convertQuerySelSet', for use in execution of
-- special case of SQL function mutations (see 'MDBFunction').
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel a bit iffy about adding a function, convertFunction, which is only used in Hasura.GraphQL.Execute.Mutation, but defined in Hasura.GraphQL.Execute.Query. It suggests there should be a module called Hasura.GraphQL.Execute.Common. Or is there a different way to resolve this?

Speaking of convertFunction, is it possible to have remote joins as part of a mutation custom function?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel a bit iffy ...

Yeah, I think it would be better to leave that for a separate PR, post- https://github.com/hasura/graphql-engine/pull/5797/files#diff-563b07c689cd5e65fabcd9d3915cb42bb1cc065d507af4ded924dba3fca9408c

Speaking of convertFunction, is it possible to have remote joins as part of a mutation custom function?

Do you mean "does that work in the PR?" or "is it possible to make it work?" ? I don't know the answer to either, but can look into it. Maybe a future enhancement?

@kodiakhq
Copy link
Contributor

kodiakhq bot commented Oct 29, 2020

This PR currently has a merge conflict. Please resolve this and then re-add the auto-update-auto-merge label.

@jberryman
Copy link
Collaborator Author

@abooij Thanks for the review. Hopefully not coming across as stubborn in how I came down on some of the suggestions here, though I did carefully (re)consider and appreciate them all. Let me know if you feel strongly about what remains open!

@jberryman jberryman requested a review from abooij November 2, 2020 14:53
...after we needed to re-use some Query.hs code in Mutate.hs
No implementation changes.

With the state of documentation of this part of the code it's hard to
say whether this is moving towards a better module structure or is just
an arbitrary change.
@jberryman jberryman force-pushed the 1514-sql-function-mutations branch from 074e4f4 to 4072bb2 Compare November 2, 2020 21:19
@jberryman
Copy link
Collaborator Author

@abooij please give a look over the last two commits. I'll rebase before merging. Thanks!

@jberryman
Copy link
Collaborator Author

@tirumaraiselvan can I get a changelog check please

### Support tracking VOLATILE SQL functions as mutations. (closing #1514)

Previously we could only track `STABLE` or `IMMUTABLE` functions, and only as
queries. Now the version 2 of `track_table` also supports tracking functions as
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo track_table?

Copy link
Contributor

@tirumaraiselvan tirumaraiselvan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changelog LGTM barring small typo.

Copy link
Contributor

@abooij abooij left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @jberryman!

@jberryman jberryman added this to the v1.3.3 milestone Nov 3, 2020
Copy link
Contributor

@tirumaraiselvan tirumaraiselvan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Metadata spec review

@jberryman
Copy link
Collaborator Author

After discussion with @tirumaraiselvan we're going to rework this with a more permissive API wrt volatility:

  • 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"
  • if that field is omitted, we'll infer expose_as from the volatility (VOLATILE implies mutation, otherwise query)

@jberryman jberryman modified the milestones: v1.3.3, v1.4 Nov 3, 2020
@jberryman
Copy link
Collaborator Author

jberryman commented Nov 3, 2020

Mmm, seems I lost the race with fd8d51a ...

Since Schema.hs will now need a full rewrite and we're changing the API significantly i'm going to close this and open a new PR that can be reviewed from scratch, which I think will be more clear.

@jberryman jberryman closed this Nov 3, 2020
@jberryman
Copy link
Collaborator Author

Progress here is blocked on some deeper review of Schema.hs changes in metadata separation PRs, see discussion in slack

@jberryman
Copy link
Collaborator Author

@marionschleifer thanks! I tried to incorporate those changes into v2 of this work, though there are a lot of changes

jberryman added a commit to jberryman/graphql-engine that referenced this pull request Nov 10, 2020
This also supports tracking VOLATILE functions as queries.

Review and discussion of the initial version of this work can be found
in this closed PR:

hasura#5858
@tirumaraiselvan tirumaraiselvan removed this from the v1.4 milestone Nov 10, 2020
jberryman added a commit to jberryman/graphql-engine that referenced this pull request Nov 12, 2020
This also supports tracking VOLATILE functions as queries.

Review and discussion of the initial version of this work can be found
in this closed PR:

hasura#5858
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

extend support for custom SQL functions (mutations, other functions types)
5 participants