https://www.prisma.io/ logo
Join Slack
Powered by
This may or may not be a stupid question but are g...
# orm-help
p
This may or may not be a stupid question but are graphql resolvers atomic? Meaning if part of the resolver fails will prisma or graphql-yoga somehow insure that the db is in the same state before the resolver was called?
j
Im assuming you refer to graphql mutations. If so, then these “atomicity” of these mutations depend on the underlying logic in their resolvers. Eg if you have multiple prisma calls, you might want to bundle them in a transaction
p
Yeah should’ve distinguished between queries
how would I do that? do you just mean the update in bulk
j
So if you have a bunch of mutations you want to do at once, you can have a look at this: https://www.prisma.io/docs/concepts/components/prisma-client/transactions This will ensure that if 1 write fails, all other writes get undone.
p
There isn’t by chance a prisma 1.34 equivalent right?
I poked around in the docs but can’t find it
maybe it’s in the prisma object
like in 2.10
j
Ah, I suppose not, they introduced this one in prisma 2. For prisma 1 I think you would need to manually undo this
p
undo it if the second mutation throws an error?
j
yeah, a try-catch around your prisma logic
p
there’s only one case where I do this, it’s when adding friends (need to put the users in each othher’s friends lists)
j
you have a single 
addFriends
mutation resolver you call? with multiple prisma calls inside the resolver?
p
yes
j
so I would put a try catch around the second mutation resolver
p
yeah I was thhinking try catch but what if the catch fails
j
if catchm, write logic that removes the results from the first mutation
you will have to make sure the catch cant fail to that end
p
yes but what if it fails at removing the results of the first
hopefully unlikely
j
then it fails, there is not much else that can be done about it
in that unlikely scenario, best thing to do is log it
if this is an edge case
when you write to databases without transactions, you cant guarantee the state of the database based on fail-state unless you write explicit logic (such as in try-catch)
p
true that would probably be good enough for now. For all the other mutations it’s whatever, if it fails it fails but it would be pretty bad to have a friend in one user friend array and not the other. I think the try catch and logging it is good enough for now but do you know if prisma 1.34 would be open to some open source contribution implementing a transaction api modeled off of the one in prisma 2?
j
If I were to guess, I would say it's unlikely, mostly because prisma1 is in that sense deprecated, and any additional logic would require them to review and test these contributions.
p
true, god damn I just need mongo db support
j
I hope they have it coming, if I recall they did have it in their roadmap
p
yeah, I asked recently and they said in 2021. Hopefully this is a minor enough issue that I can write a script that runs once a day or something that checks it’s all in order.
have you used prisma 2
do you know how it compares to prisma 1?
j
we had a transition early on this year, where we went from prisma1 to prisma2. A few growing pains, but it is by far a better product
prisma2 contains very good support for nested relation loading, much better filtering, a cleaner API, and more features such as transactions
p
that’s good to hhear and the impression I got. Prisma 1 offered a great service compared to everything else out there in my opinion but it’s pretty janky ere and there
whhat do you think about thhe script idea?
it would be expensive
but i can’t think of another way of insuring it’s all good
j
I think its a reasonable thing to do. You could use something like AWS lambda to run such a script every few hours
or your own server
p
Sweet, thanks for your help and feedback I appreciate it very much!
j
No problem 👍
Open in Slack
PreviousNext
Powered by