The fact that you have to know the name of your indexes in o Prisma #orm-help

The fact that you have to know the name of your in...

Dave Edelhart

08/11/2022, 10:33 PM

The fact that you have to know the name of your indexes in order to do “where” against a unique pair of fields is a very bad design decision. You should be able to define the where fields without having to introspect the index structure.

✅ 1

Jeremy Hinegardner

08/11/2022, 11:01 PM

@Dave Edelhart I assume you're talking about this? https://www.prisma.io/docs/reference/api-reference/prisma-client-reference#get-the-user-record-with-firstname-of-alice-and-lastname-of-smith-unique -- I 100% agree - and actually just brought this particular item up in a customer interview I just had with them @Matt Mueller (Prisma Client PM)

👍 1

Matt Mueller (Prisma Client PM)

08/11/2022, 11:18 PM

Did you try using the map param? https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#arguments-5 I haven't tried this yet myself, but I'm pretty sure there's a couple levels of defaults here, but you do have control: •

@@unique(fields: ["firstName", "lastName"])

=> leads to index and client API being firstName_lastName. Not great. •

@@unique(fields: ["firstName", "lastName"], name: "fullName")

=> index is still named firstName_lastName, client API is fullName. •

@@unique(fields: ["firstName", "lastName"], name: "fullName", map: "fullName")

=> index name and client API are fullName.

Matt Mueller (Prisma Client PM)

08/11/2022, 11:22 PM

You should be able to define the where fields without having to introspect the index structure.

In this case, we need some way to know that findUnique only takes a first name and last name. Since the index is decoupled from the SQL query, I'm not even sure knowing the name of the index matters much, as long as you have something like:

@@unique(fields: ["firstName", "lastName"], name: "fullName")

in your schema. The client will happily generate a client. In practice, you'd probably want to either have an introspection or migration loop going to keep the Prisma Schema in sync with the DB.

humblecoder

08/12/2022, 6:47 AM

Not to co-opt this thread, but index-related upserts are causing me trouble as well. Using Postgres, where case-sensitivity matters, I have a situation in which I need to use

mode:'insensitive'

. . . however, the index-esque nature of Prisma doesn’t seem to accept those params in the context of index constraints. What am I missing? 🤔

Nurul

08/30/2022, 12:46 PM

Prisma doesn’t seem to accept those params in the context of index constraints.

Can you please share the query and your model on what you are trying to achieve so that we can have a look?

6 Views

Open in Slack

Previous Next