-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Conversation
Deploy preview for hasura-docs ready! Built with commit 4945ace |
164b021
to
f5a57e9
Compare
Heterogeneous execution was merged #5869 |
0137bc9
to
0ba38d0
Compare
0ba38d0
to
731bead
Compare
server/tests-py/queries/graphql_mutation/functions/function_as_mutations.yaml
Outdated
Show resolved
Hide resolved
server/tests-py/queries/graphql_mutation/functions/function_as_mutations.yaml
Outdated
Show resolved
Hide resolved
docs/graphql/core/api-reference/schema-metadata-api/custom-functions.rst
Outdated
Show resolved
Hide resolved
-- | A pared-down version of 'convertQuerySelSet', for use in execution of | ||
-- special case of SQL function mutations (see 'MDBFunction'). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
This PR currently has a merge conflict. Please resolve this and then re-add the |
731bead
to
cf5a236
Compare
@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! |
...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.
074e4f4
to
4072bb2
Compare
@abooij please give a look over the last two commits. I'll rebase before merging. Thanks! |
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo track_table
?
There was a problem hiding this 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @jberryman!
docs/graphql/core/api-reference/schema-metadata-api/custom-functions.rst
Show resolved
Hide resolved
docs/graphql/core/api-reference/schema-metadata-api/custom-functions.rst
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Metadata spec review
After discussion with @tirumaraiselvan we're going to rework this with a more permissive API wrt volatility:
|
Mmm, seems I lost the race with fd8d51a ... Since |
Progress here is blocked on some deeper review of |
@marionschleifer thanks! I tried to incorporate those changes into v2 of this work, though there are a lot of changes |
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
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
Description
Support tracking
VOLATILE
functions as mutations (top-level fields undermutation
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 theno-changelog-required
label.Affected components
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?
Metadata
Does this PR add a new Metadata feature?
run_sql
auto manages the new metadata through schema diffing?run_sql
auto manages the definitions of metadata on renaming?export_metadata
/replace_metadata
supports the new metadata added?GraphQL
Breaking changes
No Breaking changes
There are breaking changes:
Metadata API
Existing
query
types:args
payload which is not backward compatibleJSON
schemaGraphQL API
Schema Generation:
NamedType
Schema Resolve:-
null
value for any input fieldsLogging
JSON
schema has changedtype
names have changed