Open rakeshkky opened 4 years ago
This also happens for SQL functions that return a scalar, FWIW.
Any ideas when will this be solved? I'm stuck and it's really disappointing..
Related issue: https://github.com/hasura/graphql-engine/issues/5514
When a function with an argument being a table row is tracked, then introspection query is successful. However, using its result with graphql-js
library to build a schema definition for graphiql explorer results in an error.
Example function:
CREATE FUNCTION sample_function(arg text_result) RETURNS SETOF text_result LANGUAGE sql STABLE AS $ function $
SELECT
q.*
FROM
(...) q $ function $
Error from graphql-js
:
Please prioritize this bug, it is preventing us from using computed fields. The only work around currently is to not track the postgres function, and leave the custom field. Not ideal, but at least we aren't totally stuck. Thanks so much for working on this!
Post-PDV it seems that what happens is an error is thrown in collectTypes
when trying to track a function that takes a table/composite-type argument (I haven't traced the error yet), so at least it's not possible to track such a function and get into a weird situation where the schema breaks
Computed Fields still don't work despite https://github.com/hasura/graphql-engine/commit/d236391af88f51e13be30f7c42bb12aa22389707.
I am still facing this issue. data disappears from explorer after adding custom sql function and computed field. Any workaround or fix ?
any updates on this?
via https://github.com/hasura/graphql-engine/issues/3232#issuecomment-576796667
Tracking an SQL function which returns
SETOF <table>
and type of any one of input arguments is a table row (already tracked) gives the exception described in above referred comment. User creates such functions for computed fields and tracks them as custom SQL functions.Solution:-
_input
for scalars generated for composite types. Input value for those row type scalars can be constructed as String literals (See Postgres docs). ~2. The "args" input for computed field should be named as<table>_<computed-field-name>_input_args
and not<function-name>_input_args
~ We can't change the generated type name as it breaks the schema. So, we can support solution1
by restricting tracking an SQL function as either a custom SQL function (in queries) or a computed field of a table but not both.