[Introspection] @@unique name with spaces are not supported

[irbian]

Bug description

Using introspection for creating the schema for a ugly database I found that if the index had non suported characters, they were used directly on the name, breaking the client.

The generated code:

@@index([SetType], name: "Master Index 5-2")

The workaround (that I don´t know if it will have any problems)

@@index([SetType], name: "Master_Index_5_2")

How to reproduce

Expected behavior

No response

Prisma information

Environment & setup

• OS: windows
• Database: sqlite
• Node.js version: v14.17.0

Prisma Version

prisma               : 2.27.0
@prisma/client       : 2.27.0
Current platform     : windows
Query Engine         : query-engine cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules\@prisma\engines\query-engine-windows.exe)
Migration Engine     : migration-engine-cli cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine : introspection-core cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary        : prisma-fmt cdba6ec525e0213cce26f8e4bb23cf556d1479bb (at node_modules\@prisma\engines\prisma-fmt-windows.exe)
Default Engines Hash : cdba6ec525e0213cce26f8e4bb23cf556d1479bb
Studio               : 0.410.0

[do4gr]

Hey, names in @@index should not make their way into the client api. Can you share the invalid part in the client types?

[irbian]

ups, this is only my fault

The one bugged is not @@Index, but @@unique

@@unique([Id, SubId], name: "error 1 myuniquekey")

Generates inside the index.d.ts:

  export type myTableError 1 myuniquekey = {
    Id: string
    SubId: number
  }

and another error

[do4gr]

Ok, yes that makes sense. Can you try out the just released namedConstraints preview feature of https://github.com/prisma/prisma/releases/tag/2.29.0? That should fix this particular issue by splitting the @@unique arguments into name that goes into the Client Api and map which contains the database name of the constraint. This way you will be able to create a valid client.

[irbian]

Hummm I tried, but when I did a db pull it break my schema (but don´t sweat it, the schema is an existant borked one and I myself I´m not a prisma expert)

I guess I´ll use my parsed names. Will that be a problem that the constrains on the schema and the one in db are not aligned? will the introspect work properly? I say it because after the db pull the schema shows again:

@@unique([FeatId, ClassId], name: "my name with spaces")

instead of how I understand you it will work:

@@unique([FeatId, ClassId], name: "my_name_with_spaces", map: "my name with spaces")

Edit: Nevermind, I didnt had the namedConstraints enabled, now it shows properly:

@@unique([RaceId, Category], map: "my name with spaces")

[irbian]

Regarding the "breaking", I guess is related to #1368, but I don´t know what options I have

[michael-land]

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["nApi", "filterJson", "namedConstraints"]
}

"prisma": "2.29.1",

re-introspect will remove name alias defined on model

@@id(fields: [productId, warehouseId, condition], name: "pk", map: "product_quantity_pk")

after introspect, it become

@@id([productId, warehouseId, condition], map: "product_quantity_pk")

[janpio]

Thanks for the report @xiaoyu-tamu, I split this off into its own issue: #8865

[tomhoule]

This should be fixed in prisma@dev and next week's release. Please open a new issue if you see something similar happening in the new version.