In Prisma client, with such schema, what would be ...
# orm-help
p
In Prisma client, with such schema, what would be best way to get just Posts[] by the user email?
Anything better than this?
m
Copy code
await ctx.db.post.findMany({
  where: {
    author: {
      email: "<mailto:test@example.com|test@example.com>"
    },
  },
})
or this one, not sure. Try :)
Copy code
await ctx.db.post.findMany({
  where: {
    author: {
      is: {
       email: "<mailto:text@example.com|text@example.com>"
       }
     }
   }
}
👍 1
p
Thanks, that did the trick! In my app I’m looking for single object, so I ended doing this:
Copy code
const settings = await ctx.db.settings.findFirst({
      where: { user: { email: "<mailto:test@example.com|test@example.com>" } },
    });
I’m not a 100% sure if I’m doing things the right way, maybe I should adjust my schema instead
m
There's no
settings
in the schema you pasted, I think that's schema from Prisma docs. Maybe paste your schema. In the original question you were asking about Post[] array
p
Yep yep
m
if you're quering by unique field (email) you probably want to replace findFirst with findUnique
p
So it’s weird because with findUnique I can’t query with “user” object, only with “userId”
m
Hmm actually it might be true, yes. You're right
findUniqe only by id or unique field, no relations
btw I'm storing user settings in a Json field on the user like: model User { settings Json? } Your milleage may vary depending on your needs. I have once researched subject of storing user settings and this was the path I chose. Not sure if it's gonna bite me or not. Here maybe more in comments: https://dev.to/imthedeveloper/storing-user-customisations-and-settings-how-do-you-do-it-1017 or: https://www.culttt.com/2015/02/02/storing-user-settings-relational-database
p
Yeah, I literally spoke with a colleague of mine who went this way as well, he’s not happy with that decision! 😛 I prefer strict control over the database and with the Prisma — the type-safety. Otherwise, I would pick Mongo or other NoSQL 😄
m
🙂 Yes it has pros and cons, I will probably store some settings in json and others in seperate fields tho https://stackoverflow.com/questions/22956449/saving-settings-as-json-in-database-vs-saving-them-in-extra-rows/22956853
p
Makes sense if you have large amount of settings though
I will just end with few
m
That
@unique
at
userId
is not needed probably. Btw sometimes if I need to query something very often, I prefer to store it closer to the queried model. Just to limit unnecesary relation queries. LIke in your case:
Copy code
model User { 
 isEnabled Boolean @default(false)
}
p
I’m doing GraphQL resolvers so no workaround like this allowed 😛 Will probably end with passing the userId to the context and query based on it