Risatoga
Risatoga
Explore posts from servers
PPrisma
Created by Risatoga on 10/18/2024 in #help-and-questions
Prisma extension as a Middleware to update a count
In my app, I want to keep track of the numbers of "posts" published by the user. Instead of computing them on request, I want to keep the value on the database, updating every time the user publish a new post. To do that, I am using prisma extensions. But: A- Prisma extensions do not get along with nested operations. B- If I use nested operations, I get no warning whatsoever, so it's easy to forget that, if I want to get the "middleware" working properly, I cannot use nested ops. My questions are: - Is there a way to solve B? Meaning...if I cannot used nested operations, is there a way to make it obvious so it erros when I use them? - Or is there a completely different approach that is better and I am missing? Thanks!
2 replies
PPrisma
Created by Risatoga on 10/18/2024 in #help-and-questions
Typing Json fields
I am working with prisma and when I have to save an image, I save them as json value, like this: " model Tattoo { //... image Json //... } " then the image field is an object with fields like "publicUrl", "fileName", "fileSize" The problem is that with this approach, prisma offers no validation or types for the image field: I can add images that do not fit in the expected shape. What other approach could I use to make my image field more "type safe"? I am now using Prisma Json types as recommended in: https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types/working-with-json-fields but that is "clashing" with zod-prisma-types (https://www.npmjs.com/package/zod-prisma-types) which is a library I enjoy a lot using... Basically, while both keep doing their work, as zod-prisma-types is based on the prisma schema file, and there the json file is not type, the types and schemas generated by it are too wide (aka: not applying the types generated by json type generator) Is there any fix?
5 replies
PPrisma
Created by Risatoga on 4/13/2024 in #help-and-questions
How to Implement an Optional One-to-One Relationship in Prisma with MongoDB?
Context I'm using Prisma 5.10.2 with MongoDB and attempting to set up an optional one-to-one relationship between two models based on the official Prisma documentation. However, I've encountered a problem with MongoDB's support for nullable unique fields. Models Here are the models I'm using (the ones recommended in the docs actually)
model User {
id String @id @default(auto()) @map("_id") @db.ObjectId
profile Profile? @relation(fields: [profileId], references: [id])
profileId String? @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
}

model Profile {
id String @id @default(auto()) @map("_id") @db.ObjectId
user User?
}
model User {
id String @id @default(auto()) @map("_id") @db.ObjectId
profile Profile? @relation(fields: [profileId], references: [id])
profileId String? @unique @db.ObjectId // relation scalar field (used in the `@relation` attribute above)
}

model Profile {
id String @id @default(auto()) @map("_id") @db.ObjectId
user User?
}
` Issue MongoDB does not support "nullable uniques," which means that users without a profile (where the profile property is null) are not unique and cause write operations to fail. Possible Solutions I've Considered - Changing to a One-to-Many Relationship: Modify the User model to handle an array of profiles but only use the first item. This approach seems hacky as it deviates from the intended one-to-one relationship structure. - Making the Profile Required: This would ensure uniqueness but defeats the purpose of the relationship being optional. Question Is there a standard approach to implementing optional one-to-one relationships in Prisma with MongoDB that avoids these issues, or is adapting one of the hacky solutions the only way? I'm relatively new to this (been learning for about 8 months), so any guidance or alternative suggestions would be greatly appreciated. Thank you!
4 replies