https://www.prisma.io/ logo
Join Slack
Powered by
how can I extract all fields on the `Prisma.query....
# orm-help
m
how can I extract all fields on the 
Prisma.query.users()
call? e.g. if I do
Copy code
await Prisma.query.users(data, `{ id email tasks { id } }`)
but it's unmaintainable for bigger models: is there 
GraphQLResolveInfo
option to resolve all?
c
I feel like that kind of goes against the philosophy of graphQL, in that you only retrieve what you explicitly need. Are you sure your client is always going to need all fields for the given resource?
m
I'm trying to compute properties with custom returned schema
namely: some 
meta
statistics (e.g. 
numberOfTasks
)
in theory: yes, client could resolve all 
tasks
from 
user
and count total themselves but I'd like to expose some data for dashboard purposes
e
You could do something along the lines of 
Fragment Tasks on User { ... }
so it is reusable, and a little less verbose when you want that data
👍 1
c
If all you really want is to expose a way to get the # of tasks that a given user has, I think you could extend your graphQL schema (not your prisma schema) to add a 
numberOfTasks
property and make the resolver something like 
prisma.taskConnection({ where: { user: { id: parent.id } } }).aggregate().count()
👍 1
m
the number of tasks is the easiest example; I'd also want a little bit more complex examples nested inside: e.g. % completed tasks, % not started tasks, % finished by X
I'm expecting to be doing this work within the resolver but first I need to fetch all tasks - for now, I can easily call the query and fetch what I need but for more complex models, I'd rather not hardcode it and just "fetch all properties of a model"
but thank you for suggestions 👍
c
I see. For some aggregate/calculation-based fields I’ve resorted to querying the DB directly using 
knex
. Eg:
Copy code
other props...,
averageSentiment(parent) {
      return db.survey('average_provider_sentiment').select('avg')
        .where('id', parent.id)
        .then(data => (data.length > 0 ? data[0].avg : null))
        .catch(err => new Error(err))
    },
You kind of lose the single-access point that prisma gives you but if your schema is pretty well set and unlikely to change it can work
Not sure what the ETA for prisma allowing raw SQL querying is.
m
we have few special cases where we see an advantage of having Query return custom schema with calculation-based computed properties added on top of them
we're not expecting to expose those APIs to general public but only within our internal, custom built Electron app so I feel like it's an acceptable workaround
knex
seems like an interesting solution, thanks for proposing that
c
Sure thing. It’s what I’ve mostly used pre-Prisma. I like it more than more robust ORMs especially for simple queries.
fast parrot 1
3 Views
Open in Slack
PreviousNext
Powered by