Prisma•13mo ago•

10 replies

strictUndefinedChecks undesired behavior

hey,

I am really happy to see the new preview feature

strictUndefinedChecks

strictUndefinedChecks

. However, I did run into some confusion testing.

When using it I notice that errors are thrown during create and update operations, specifically when an undefined value is used in the data object of the query.

Using the following schema as an example:

model TrpcQueries {
  id            Int      @id @default(autoincrement())
  correlationId String
  path          String
  duration      Int
  userId        String?
  ipv4          String?
  createdAt     DateTime @default(now())

  User User? @relation(fields: [userId], references: [id])

  @@index([userId])
  @@index([correlationId])
}

model TrpcQueries {
  id            Int      @id @default(autoincrement())
  correlationId String
  path          String
  duration      Int
  userId        String?
  ipv4          String?
  createdAt     DateTime @default(now())

  User User? @relation(fields: [userId], references: [id])

  @@index([userId])
  @@index([correlationId])
}

In this schema,

ipv4

ipv4

is optional. However, when I use a header that might be

undefined

undefined

, like so:

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for'),
  },
});

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for'),
  },
});

I was wondering why an

undefined

undefined

value isn’t allowed here. If undefined values are indeed disallowed, wouldn’t it be helpful if the types only accepted a

string

string

null

null

instead? This way, any potential issues could be caught during development instead of at runtime.

Prisma•13mo ago•

10 replies

Peform

strictUndefinedChecks undesired behavior

hey,

I am really happy to see the new preview feature

strictUndefinedChecks

strictUndefinedChecks

model TrpcQueries {
  id            Int      @id @default(autoincrement())
  correlationId String
  path          String
  duration      Int
  userId        String?
  ipv4          String?
  createdAt     DateTime @default(now())

  User User? @relation(fields: [userId], references: [id])

  @@index([userId])
  @@index([correlationId])
}

model TrpcQueries {
  id            Int      @id @default(autoincrement())
  correlationId String
  path          String
  duration      Int
  userId        String?
  ipv4          String?
  createdAt     DateTime @default(now())

  User User? @relation(fields: [userId], references: [id])

  @@index([userId])
  @@index([correlationId])
}

In this schema,

ipv4

ipv4

is optional. However, when I use a header that might be

undefined

undefined

, like so:

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for'),
  },
});

await prisma.trpcQueries.create({
  data: {
    correlationId: "id...",
    path: "path",
    duration: 123,
    ipv4: ctx.headers?.get('x-forwarded-for'),
  },
});

I was wondering why an

undefined

undefined

value isn’t allowed here. If undefined values are indeed disallowed, wouldn’t it be helpful if the types only accepted a

string

string

null

null

instead? This way, any potential issues could be caught during development instead of at runtime.

strictUndefinedChecks undesired behavior

Similar Threads

strictUndefinedChecks undesired behavior

Similar Threads

Similar Threads

Similar Threads