Hasura doesn't find custom type declared in a schema other than public

[zolamk]

When declaring a custom type in hasura in a schema other than public and trying to use it on a column, it's not being listed as column type, we can get past that by declaring the column using the SQL tool in data but then when trying to filter based on that column i keep getting a constraint-error

for example

let's say i have the schema interview and i declare the following custom type

create type interview.status_type as enum('pending', 'disqualified');

and then i use the declared type in another sql statement creating a column

alter table interview.person_interviews add column status interview.status_type not null default 'pending'

and then say i were to run the following graphql query

{
  interview_person_interviews(where: {status: {_eq: "pending"}}) {
    id
  }
}

after running the above query i get the following error

{
  "errors": [
    {
      "extensions": {
        "path": "$",
        "code": "constraint-error"
      },
      "message": "type \"status_type\" does not exist"
    }
  ]
}

[maguszoldik]

Just had the same issue and took me a while to find out why. For now I can avoid the failure by creating the new type in the public schema, not ideal (breaks our namespacing conventions) but works.

Nevertheless, we have another existing database that we would like to use with Hasura, sadly this issue will be a deal breaker as moving types will not be an option.

Hope this will be fixed.

[kraf]

It's been some time since the last update on this issue. Are there plans to tackle this? Are you accepting pull requests for this?

[lossendae]

Any news on this subject ? But my mistake, this is still not fixed in beta 2 (?)

On my test on similar case with the beta 2, I can read a field with a custom type not in the public schema, but run mutation on it :

{
  "errors": [
    {
      "extensions": {
        "path": "$",
        "code": "constraint-error"
      },
      "message": "type \"my_custom_type\" does not exist"
    }
  ]
}

[florence-henry]

Hello

Any news for this issue ? I have the same problem with 2.0.9 ( #7648).

It is suboptimal to change our data policy because of a s/w problem.

Do you need help for testing ?

[xbonnin]

Same issue for me.

[lossendae]

Still no news on this ?

[klondikedragon]

I'm affected by this as well (trying to do an update mutation on a table with a custom enum type in a non-default namespace, and it gives the "type xxx does not exist" because Hasura construct SQL that contains a non-qualified typename in the constructed SQL). There was a related bug #4014 that was just fixed in https://github.com/hasura/graphql-engine/commit/d5610242542eb10c8d3ba825f2bd34fb23fb4faf.

@rakeshkky @0x777 Maybe this commit lays the foundation for fixing this one? This is pretty severe as it completely blocks using Hasura with any PostgreSQL database that has a custom enum type in a non-default schema.

To fix, it seems like first PGScalarType, PGEnumScalar type would need to contain both a namespace and a typename: https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L321

This would affect areas that construct a PGEnumScalar where it needs to add the namespace as well, such as: https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L437

Then, when the PGEnumScalar is translated to SQL text, it would need to add the namespace and not just the typename: https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L361 https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L368

There is already a concept in the code for qualified type names, QualifiedPGType, so maybe it's just a matter of constructing a fully qualified type name instead of just the PGEnumScalar in the right place. https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L525

It might be as simple as adding another case taking a QualifiedPGType and constructing the proper PGEnumScalar with the schema name included: https://github.com/hasura/graphql-engine/blob/master/server/src-lib/Hasura/Backends/Postgres/SQL/Types.hs#L558

I'm not familiar at all with Hasura code. But it seems most of the infrastructure is there to fix this, hopefully it would be a quick fix for someone familiar with the code.

[kulame]

Same issue for me.

What is the latest status on this issue?

[davidpanic]

This issue still exists in Hasura v2.12.0. Queries work fine but mutations complain that the type "does not exist". Are there any plans on fixing this?

[davidpanic]

Our current workaround is PostgreSQL domains which is not ideal. We are using the postgres rrule extension, so we ran the following to add public domains for the types:

CREATE DOMAIN rrule AS _rrule.rrule;
CREATE DOMAIN rruleset AS _rrule.rruleset;

[d-baranowski]

In Postgres you can run something like this to make this work: alter database DB_NAME set search_path = public, SCHEMA_ONE, SCHEMA_TWO, SCHEMA_ETC;

[lossendae]

In what way changing the search_path in a pg console helps hasura ?

[d-baranowski]

That setting is global for the database. Issue mentions that hasura fails to find the type in the correct schema. If you change the sarch_path you will no longer need to prefix the enum type with the schema name because postgres will find it using the search path.

[florence-henry]

This solution is working. Thanks !

I did not know search_path could be set globally.

[ezequielmasciarelli]

I managed to fix it by appending the schema to the HASURA_GRAPHQL_DATABASE_URL env variable

postgres://.../my_db?options=-c%20search_path%my_schema,public

[tmihalik]

I managed to fix it by appending the schema to the HASURA_GRAPHQL_DATABASE_URL env variable

postgres://.../my_db?options=-c%20search_path%my_schema,public

the appropriate full format: postgres://user:pass@host:5432/dbname?options=-c%20search_path%3Dmy_schema%2Cpublic

[clluiz]

Any news on this?