Prisma•2mo ago

getting data from prismaClient says field might be null when it literally isn't in the schema

i have this in my schema

model products {
  id             Int       @id @default(autoincrement())
  //some fields
  recommended    Boolean   @default(false)  
  //more fiels
}

model products {
  id             Int       @id @default(autoincrement())
  //some fields
  recommended    Boolean   @default(false)  
  //more fiels
}

so recommended is obviously NON NULL and it has a default value, i even see in my database as non null, but when i get the data from prismaClient it says that recommended is of type boolean | null

  const data = await prismaClient.products.findMany({
    where: {
      recommended: true,
    },
    select:{
      id:true,
      //other fields
      recommended:true,
    }
  });

  const data = await prismaClient.products.findMany({
    where: {
      recommended: true,
    },
    select:{
      id:true,
      //other fields
      recommended:true,
    }
  });

6 Replies

Prisma AI Help•2mo ago

Skipping coffee for instant knowledge! Let's brew that AI answer now.

Saturn 🪐OP•2mo ago

i did npx prisma db pull and npx prisma generate multiple times, still nothing i already hate the fact that i have to cast Decimal to number, but this shouldn't be this way +i'm using postgres as a database

Prisma AI Help•2mo ago

Based on the information provided in the knowledge sources, I can explain why you're experiencing this behavior with Prisma Client. The issue you're encountering is not related to how the field is defined in your schema or stored in the database. Instead, it's related to how Prisma Client handles nullable fields in TypeScript. Prisma Client generates TypeScript types that represent the models in your application code. These types are designed to be safe and account for various scenarios, including potential null values, even when the field is defined as non-nullable in the schema. This behavior is intentional and is part of Prisma's type system. It's designed to handle edge cases and ensure type safety across different operations. Unfortunately, the knowledge sources don't provide a direct solution to change this behavior. However, there are a couple of approaches you can consider: 1. You can use a type assertion in TypeScript to tell the compiler that you're certain the field is not null:

const data = await prismaClient.products.findMany({
  where: {
    recommended: true,
  },
  select:{
    id: true,
    recommended: true,
  }
}) as Array<{ id: number; recommended: boolean }>;

const data = await prismaClient.products.findMany({
  where: {
    recommended: true,
  },
  select:{
    id: true,
    recommended: true,
  }
}) as Array<{ id: number; recommended: boolean }>;

2. Alternatively, you can use a non-null assertion operator (!) if you're absolutely sure the field will never be null:

data.forEach(product => {
  console.log(product.recommended!);
});

data.forEach(product => {
  console.log(product.recommended!);
});

However, use these approaches with caution, as they override TypeScript's type checking. It's worth noting that this behavior has been a topic of discussion in the Prisma community. There's an open issue on GitHub discussing the distinction between null and undefined values, which is related to your question: MongoDB: Distinguish null and undefined return values. While this doesn't directly address your specific case with a non-nullable field, it shows that the Prisma team is aware of the complexities around null handl ing and type generation. If you need more precise control over the generated types, you might want to consider creating a feature request on the Prisma GitHub repository to allow for stricter type generation for non-nullable fields with default values. 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.

Saturn 🪐OP•2mo ago

i have another field marked as

  detail    String   @db.VarChar

  detail    String   @db.VarChar

in the schema but is also marked as potential null, wth?

begot•2mo ago

Prisma deliberately generates types that include null as a possibility, even when your schema fields are non-nullable to handle edge cases in database operations. for example, if a field selection is dynamic or if there are complex joins. here's how to work around this behavior:

// 1. Define the type for your selected fields
type ProductSelection = {
  id: number;
  detail: string;
  recommended: boolean;
};

// 2. Use it with your Prisma query
const data = await prismaClient.products.findMany({
  where: { recommended: true },
  select: {
    id: true,
    detail: true,
    recommended: true,
  }
}) as ProductSelection[];

// 1. Define the type for your selected fields
type ProductSelection = {
  id: number;
  detail: string;
  recommended: boolean;
};

// 2. Use it with your Prisma query
const data = await prismaClient.products.findMany({
  where: { recommended: true },
  select: {
    id: true,
    detail: true,
    recommended: true,
  }
}) as ProductSelection[];

since you know your schema guarantees these fields can't be null, this type assertion is safe to use and gives you cleaner types to work with in your code. someone at Prisma can correct me if i'm wrong here.

Saturn 🪐OP•2mo ago

yeah i ended up using a type assertion because while searching i learned that for some reason postgres can have true, false and null for boolean ehich is weird

Gaming

Programming

getting data from prismaClient says field might be null when it literally isn't in the schema

Did you find this page helpful?