-
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
Hasura doesn't find custom type declared in a schema other than public #4630
Comments
Just had the same issue and took me a while to find out why. 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. |
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? |
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"
}
]
} |
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 ? |
Same issue for me. |
Still no news on this ? |
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 d561024. @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 This would affect areas that construct a Then, when the There is already a concept in the code for qualified type names, It might be as simple as adding another case taking a 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. |
Same issue for me. What is the latest status on this issue? |
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? |
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; |
In Postgres you can run something like this to make this work: |
In what way changing the |
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. |
This solution is working. Thanks ! I did not know |
I managed to fix it by appending the schema to the HASURA_GRAPHQL_DATABASE_URL env variable postgres://.../my_db |
the appropriate full format: |
Any news on this? |
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
…st_status [Hasura is currently unable to properly use custom types not in the public schema] (hasura/graphql-engine#4630). While this can be partially circumvented by specifying a search_path in the connection string (see change to Docker Compose), because these two types share a name, Hasura would always match to the type specified in the first listed schema in the search path. Because these types are identical sans the originating DB, they were combined into a singular type, `request_status`, rather than renaming each one.
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 aconstraint-error
for example
let's say i have the schema
interview
and i declare the following custom typecreate 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
after running the above query i get the following error
The text was updated successfully, but these errors were encountered: