This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-08
Channels
- # aleph (52)
- # beginners (74)
- # boot (8)
- # cider (4)
- # clara (3)
- # cljs-dev (1)
- # cljsjs (2)
- # cljsrn (1)
- # clojars (2)
- # clojure (300)
- # clojure-argentina (1)
- # clojure-dev (9)
- # clojure-italy (10)
- # clojure-nl (1)
- # clojure-russia (77)
- # clojure-sg (9)
- # clojure-spec (38)
- # clojure-uk (70)
- # clojurescript (108)
- # core-async (12)
- # cursive (9)
- # data-science (4)
- # datascript (7)
- # datomic (37)
- # defnpodcast (4)
- # emacs (11)
- # graphql (6)
- # jobs (3)
- # jobs-discuss (1)
- # juxt (3)
- # keechma (1)
- # klipse (4)
- # lein-figwheel (1)
- # lumo (1)
- # off-topic (3)
- # om (5)
- # onyx (10)
- # parinfer (3)
- # pedestal (1)
- # perun (1)
- # protorepl (3)
- # re-frame (35)
- # reagent (19)
- # spacemacs (4)
- # specter (2)
- # uncomplicate (279)
- # unrepl (32)
Hi, I am wondering if there is any order-of-execution guarantees for the fields inside of a mutation? e.g does the spec propose they execute in the order they are listed in the graphql string? e.g
mutation {
foo {
bar
baz
}
}
--
The order of execution of bar and baz is what I am interested in.I am aware that root mutation field resolvers must be executed in order, but I am not so sure about the child field resolvers
The reason for this is to express a kind of transactional context in which one can describe a variety of different operation (each a field like bar or baz) so that they can be committed all at once
Just found this: https://github.com/graphql/graphql-js/issues/221
The spec is very clear on this: the top level operations run sequentially, but nested fields run with the same semantics as an ordinary query. In addition, in Lacinia, the top-level field resolver exits entirely before nested resolvers are invoked, so you won't be able to implement transaction semantics anyway. It could be done in the Pedestal pipeline instead.