When writing a mutation resolver for Graphql-yoga ...
# prisma-whats-newb
Bro
03/26/2018, 6:26 PMWhen writing a mutation resolver for Graphql-yoga -> Prisma, what's the best way to ensure integrity? For instance, I want to move a coin from player1's account, if it exists, to player2's, but not have problems with coins replicating or disappearing.
d
Daniel K.
03/26/2018, 6:42 PMI think I've read somewhere that nested mutations are atomic
Daniel K.
03/26/2018, 6:42 PMb
Bro
03/26/2018, 6:43 PMAwesome!
d
Daniel K.
03/26/2018, 6:43 PMhaven't tested that tho, not sure how reliable it is 🙂
b
Bro
03/26/2018, 6:49 PMA paragraph in the docs is all the assurance I need. 🐿️
Bro
03/26/2018, 8:21 PMSo how would you wrap multiple updates in the same mutation? If you do something like this:
Copy code
mutation{
a: updatePlayer(
where:{name:"p1"}
data:{totalCoins:2})
{
name
totalCoins
}
b: updatePlayer(
where:{name:"no-exist"}
data:{totalCoins:3}
)
{
name
totalCoins
}
}n
nilan
03/27/2018, 4:58 PMThat's an interesting discussion, thanks for bringing it up @Bro. We are thinking about supporting transactions across multiple top level mutations. There has been some discussion about that here:https://github.com/graphcool/prisma/issues/74 Would love to hear your take on this in the issue 🙂
b
Bro
03/27/2018, 5:02 PMI was reading that earlier. Will do.
🙏 1
Bro
03/27/2018, 5:20 PMHarmony and I were discussing this in a thread today. One of the problems with this case would be double spending. It looks like you would need to wrap a query as well as both mutations in a transaction to ensure that the resolver wasn't hit multiple times. It may be better have the resolver make a custom sql call directly on the database or through Prisma, if that becomes a feature. Especially if you start doing more complicated exchanges.
n
nilan
03/27/2018, 6:12 PMThat's certainly a possible approach. We're exploring raw SQL queries as a general fallback strategy already, and will detail our thoughts here soon: https://github.com/graphcool/prisma/issues/2052.
b
Bro
03/27/2018, 8:40 PMI commented on issue 74. To summarize: I can almost accomplish this with nested queries, but can't guarantee that double spending won't take place. If there was something in addition to
where: PlayerWhereUniqueInput!andWhere: [PlayerWhereInput!]n
nilan
03/28/2018, 9:18 AMthanks for your input! 🙂 for now, you can also think about locking the mutation in your GraphQL Server layer instead
b
Bro
03/29/2018, 5:37 PMCurrently, the solution I came up with was adding a
lastState: someUUIDwhere: PlayerWhereUniqueInput