This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-17
Channels
- # aws (16)
- # beginners (82)
- # boot (29)
- # cider (43)
- # cljs-dev (90)
- # cljsrn (14)
- # clojure (79)
- # clojure-dev (12)
- # clojure-greece (4)
- # clojure-italy (12)
- # clojure-russia (81)
- # clojure-shanghai (1)
- # clojure-spec (39)
- # clojure-uk (28)
- # clojurescript (159)
- # consulting (1)
- # cursive (16)
- # data-science (6)
- # datomic (18)
- # devops (3)
- # emacs (22)
- # figwheel (1)
- # graphql (15)
- # hoplon (3)
- # jobs (1)
- # jobs-discuss (8)
- # leiningen (1)
- # luminus (6)
- # lumo (1)
- # off-topic (18)
- # om (6)
- # onyx (38)
- # pedestal (30)
- # perun (3)
- # re-frame (38)
- # reagent (8)
- # ring-swagger (2)
- # rum (2)
- # sql (2)
- # unrepl (14)
- # untangled (1)
- # vim (8)
stijn: Discussion about a specific issue is best in the issue; general discussion or planning for future enhancements is good right here.
our 'update' and 'create' resolvers are very generic and use the type information from the graphql schema to convert the input to a datomic transaction
this means that we need to inspect the input args, get their type from the schema and do the conversion
on the query side we don't use selection as with datomic entities you don't have the SQL n+1 problem
stijn: Discussion about a specific issue is best in the issue; general discussion or planning for future enhancements is good right here.
That seems like a bug to me; the spec goes into a lot of detail about handling of input (what we might call conforming of inputs, w.r.t. to clojure.spec). I'm a bit surprised that there's an issue with an variable value of type Int or Long and an argument of type GraphQL Int.