Using the @unique constraint gives an error when Hasura tries to track the tables that use it

Bug description

When I use an @unique constraint on a field (required or optional) and then try to use the table containing that field in Hasura, it gives an error saying:

Adding existing table/view failed

“cannot include model.field_unique” in the GraphQL schema because it is not a valid GraphQL identifier"

model => the model name field => the name of the field with the constraint @unique

How to reproduce

1. Create two models to confirm

model RequiredUnique {
  id    String  @id @default(uuid())
  email String @unique
}

model OptionalUnique {
  id    String  @id @default(uuid())
  email String? @unique
}

1. Push the changes to a local/remote Postgres instance

prisma db push --preview-feature

1. Use local/remote Hasura instance
2. Add the Postgres instance as a datasource to the Hasura instance
3. Search for the created schema in Hasura
4. Track the RequiredUnique or OptionalUnique tables

According to Phpstorm, the tables are being created with the following SQL:

-- auto-generated definition
create table "RequiredUniqueTest"
(
    id    text not null
        constraint "RequiredUniqueTest_pkey"
            primary key,
    email text not null
);

alter table "RequiredUniqueTest"
    owner to postgres;

create unique index "RequiredUniqueTest.email_unique"
    on "RequiredUniqueTest" (email);

-- auto-generated definition
create table "OptionalUniqueTest"
(
    id    text not null
        constraint "OptionalUniqueTest_pkey"
            primary key,
    email text
);

alter table "OptionalUniqueTest"
    owner to postgres;

create unique index "OptionalUniqueTest.email_unique"
    on "OptionalUniqueTest" (email);

From what I see, the error that Hasura gives is because the index is being created with a “.” instead of “_”, and that’s weird because in the docs you always use “_”, never “.” when creating a unique index.

The unique constraint works well with the Prisma client, the problem only arises in this case.

Expected behavior

Use the @unique constraint without problem when a service such as Hasura tries to use the same Postgres DB that Prisma has migrated.

Environment & setup

• OS: Windows 10
• Database: PostgreSQL
• Node.js version: v14.15.1
• Prisma version:

Environment variables loaded from .env
prisma               : 2.19.0
@prisma/client       : 2.19.0
Current platform     : windows
Query Engine         : query-engine c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at node_modules\@prisma\engines\query-engine-windows.exe)
Migration Engine     : migration-engine-cli c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine : introspection-core c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary        : prisma-fmt c1455d0b443d66b0d9db9bcb1bb9ee0d5bbc511d (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Studio               : 0.358.0
Preview Features     : createMany

[do4gr]

A fix for this issue is now available via the namedConstraints preview flag since 2.29. We now have a default naming convention without invalid characters. See https://www.prisma.io/docs/guides/upgrade-guides/upgrading-to-use-preview-features/enabling-named-constraints

[janpio]

Yes, https://github.com/prisma/prisma/issues/6680 is being worked on and will change the index naming in a way that should make it compatible with Hasura.