How to have ID type in schema for primary keys?

[beepsoft]

Hi,

it seems that Hasura doesn't generate the graphql type ID (https://graphql.github.io/graphql-spec/June2018/#sec-ID) for primary keys. Instead it generates a scalar type matching the type of the primary key in the database.

So, in case my primary key is a bigint then in the schema I will have

scalar bigint

type todo {
  id: bigint!
  ...
}

The problem is that other tools (eg. https://github.com/mobxjs/mst-gql) depend on the existence of a unique identifier for types and expects it to be the one field with type ID.

Would it be possible to have a Hasura server setting / environment variable, which enables generation of ID types for primary fields instead of the default mechanism?

[wc-matteo]

I was looking for the same thing. It would be quite useful!

For example apollo uses it for caching.

[bram209]

any update on this?

[tirumaraiselvan]

Related: https://github.com/hasura/graphql-engine/issues/3578

[philschonholzer]

The new Remote Relationships with v1.3 do not work with Sanity.io because their id's are of type ID! which Hasura does not support. Using another type like uuid! gets you an exception when trying to create a new remote relationships:

[
    {
        "definition": {
            "remote_field": {
                "allPackages": {
                    "arguments": {
                        "where": {
                            "_id": {
                                "eq": "$package_id"
                            }
                        }
                    }
                }
            },
            "name": "Package_ID",
            "hasura_fields": [
                "package_id"
            ],
            "remote_schema": "Sanity",
            "table": {
                "schema": "public",
                "name": "Orders"
            }
        },
        "reason": "in table \"Orders\": in remote relationship\"Package_ID\": cannot validate remote relationship because expected type \"ID\" but got \"uuid\"",
        "type": "remote_relationship"
    }
]

A possible solution would be to define the type that is needed by a remote schema (like ID!)

[tirumaraiselvan]

@philschonholzer One workaround suggested in community regarding sanity.io is here: https://discord.com/channels/407792526867693568/516590536875048990/727192434391646351

Quoting:

ended up adding a new field with a different id as a string. Not ideal but I don't see a way to change the type for the id schema as its autogenerated. The string works great though. thanks again.

[kamescg]

I am getting this same issue, but I actually have an Int type and not ID... which still causes an issue even though the types match.

cannot validate remote relationship because expected type "Int" but got "Int"

I'm attempting to integrate the Monday.com Item schema.

https://monday.com/developers/v2#queries-section-items

Any thoughts when this issue will be resolved?

[tirumaraiselvan]

@kamescg Seems like you might be hitting this issue: https://github.com/hasura/graphql-engine/issues/5133

[jacdx]

Is this issue on the roadmap? It has turned into a blocker for us, as we can't use Remote Schemas as-is, since they depend on IDs that are shared across systems (uuids in Hasura).

[adrien-mg]

Do we have any update on this? This is a blocker for us too trying to integrate with Strapi which uses ID as a type for its collections :disappointed:

in table "origin_table": in remote relationship "remote_table": cannot validate remote relationship because expected type "ID" but got "Int"

[aaka3207]

This has also become a major blocker for us, we're trying to integrate Sanity.io with Hasura but are unable to. Any movement on this?

[willrbc]

I'm having a similar issue where my remote scheme expects a Long for its ID and hasura is giving bigint as the type of the primary key field.

Perhaps need a way to cast fields as types when doing a remote schema join?

I also believe it would be useful to support the ID field too.

[eriklofblad]

I'm having the same issue when trying to add remote relationship to Sanity. It seems like this issue applies to a whole lot of usecases for remote relationships. Any updates?