P
Prisma•3mo ago
antoine

Typing Prisma and how write "or" and a named type (prisma ORM/mongodb)

Hello i would like to know how can i write or typed that with Prisma (mongodb DB). I don't know how to write 'or' with Prisma or a named value/type. I know I can mark it as json then any in typescript but I'd like to know if it's possible to type something like this Do you have any ideas ? Thank you very much export interface Offer { id: string originalPrice: string discountedPrice: string changes: Changes[] } interface AddVariantChange { type: 'add_variant' variantId: number quantity: number discount: Discount | null } export interface AddShippingLineChange { type: 'add_shipping_line' price: number title?: string presentmentTitle?: string } type Changes = AddVariantChange | AddShippingLineChange
1 Reply
Prisma AI Help
Prisma AI Help•3mo ago
You opted for speed from this bot. Let's conjure up an answer right now! To answer your question about typing complex structures like unions and named types in Prisma with MongoDB, I'll need to provide some important context and limitations first. Prisma's schema language doesn't directly support union types or complex nested structures like the one you've described. However, there are a few approaches you can consider: 1. Using JSON fields: You can use a JSON field to store the complex structure and then use TypeScript types to provide type safety in your application code. This is likely the most flexible approach for your specific case.
model Offer {
id String @id @default(auto()) @map("_id") @db.ObjectId
originalPrice String
discountedPrice String
changes Json
}

model Offer {
id String @id @default(auto()) @map("_id") @db.ObjectId
originalPrice String
discountedPrice String
changes Json
}

Then in your TypeScript code, you can define the types as you've shown and use them to type the JSON field:
import { Offer as PrismaOffer } from '@prisma/client'

// Your type definitions here (Offer, Changes, etc.)

// Extend the Prisma-generated type
interface FullOffer extends Omit<PrismaOffer, 'changes'> {
changes: Changes[]
}

import { Offer as PrismaOffer } from '@prisma/client'

// Your type definitions here (Offer, Changes, etc.)

// Extend the Prisma-generated type
interface FullOffer extends Omit<PrismaOffer, 'changes'> {
changes: Changes[]
}

2. Using composite types (MongoDB only): Prisma supports composite types for MongoDB, which can help model nested structures. However, they don't support union types directly. You might need to simplify your model or use a combination of composite types and JSON fields.
model Offer {
id String @id @default(auto()) @map("_id") @db.ObjectId
originalPrice String
discountedPrice String
changes Change[]
}

type Change {
type String
variantId Int?
quantity Int?
discount Json?
price Float?
title String?
presentmentTitle String?
}

model Offer {
id String @id @default(auto()) @map("_id") @db.ObjectId
originalPrice String
discountedPrice String
changes Change[]
}

type Change {
type String
variantId Int?
quantity Int?
discount Json?
price Float?
title String?
presentmentTitle String?
}

This approach doesn't fully capture the union type structure, but it allows for some level of typing in the Prisma schema. 3. Using a third-party solution: As mentioned in the Prisma documentation on table inheritance, you can consider using third-party solutions like Zenstack, which adds features to the Prisma schema. However, this might introduce additional complexity to your project. For the "OR" operator in Prisma queries, you can use it as follows:
const result = await prisma.offer.findMany({
where: {
OR: [
{ originalPrice: { contains: 'value1' } },
{ discountedPrice: { contains: 'value2' } }
]
}
})
const result = await prisma.offer.findMany({
where: {
OR: [
{ originalPrice: { contains: 'value1' } },
{ discountedPrice: { contains: 'value2' } }
]
}
})
This is documented in the Prisma Client API reference for OR. In conclusion, while Prisma doesn't natively support complex union types in its schema, you can use JSON fields with TypeScript types, simplify your model using composite types (for MongoDB), or consider third-party solutions. The choice depends on your specific requirements and the trade-offs you're willing to make between schema simplicity and type safety. 🤔 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.

Did you find this page helpful?