[suggestion]: Please make prisma studio's query less restrictive

Schema

model User {
  id                 String              @id @default(cuid())
  email              String              @unique
  firstName          String?
  lastName           String?
  gender             Gender?
  dateOfBirth        DateTime?
  phoneNumber        String?
  createdAt          DateTime            @default(now())
  updatedAt          DateTime            @updatedAt
  shoppingPreference ShoppingPreference?

  productsInCart     ProductsInCart[]
  productsInWishlist ProductsInWishlist[]

  @@map("users")
}

model ProductsInWishlist {
  id        String   @id @default(cuid())
  product   Product  @relation(fields: [productId], references: [id])
  productId String
  User      User     @relation(fields: [userId], references: [id])
  userId    String
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt

  @@unique([userId, productId])
  @@index([userId, productId])
  @@map("products_in_wishlists")
}

Problem

Currently, when you have a bad data, from the schema above, where the userId or the productId doesn't exist, it will crash prisma's studio on that table with this error Inconsistent query result: Field User is required to return data, got null instead. While, the only solution is to actually clears the data of the entire table, or you would have to manually do a sql command in your database to delete that bad data. I believe a lot of people were facing this scenario, but didn't know what the issue were.

Solution

Rather than preventing user from accessing the table in the first place, it would be much better to allow the user to still access the table on prisma studio, and then they can delete it by themself rather than spending quite some time to either nuke the table or manually deleting that item.

The problem is not Prisma Studio, but Prisma Client. And Prisma Client can not do anything about this, as the Prisma Schema that you provide is the basis for everything it knows. The types are generated based on it, all logic is based on it - including the one that throws the error message you are getting. Building a mode where the Client knows both about what the data should look like and still accepts data in other formats would be a lot of work with small impact.

You could run db pull to update your Prisma schema to reflect the database schema, and hence not being able to return any invalid data instead. Then you can use Studio to filter for the cases you do not want and replace them, then update the database and Prisma schema via db pull again to have the tighter version.

prisma / studio