This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-13
Channels
- # announcements (34)
- # aws (1)
- # beginners (99)
- # boot (19)
- # calva (26)
- # cider (24)
- # cljdoc (8)
- # cljs-dev (29)
- # clojure (107)
- # clojure-dev (3)
- # clojure-europe (12)
- # clojure-finland (1)
- # clojure-italy (24)
- # clojure-nl (5)
- # clojure-spec (13)
- # clojure-sweden (3)
- # clojure-uk (36)
- # clojurescript (4)
- # community-development (14)
- # cursive (3)
- # data-science (6)
- # datascript (57)
- # figwheel-main (3)
- # fulcro (9)
- # graalvm (11)
- # hoplon (18)
- # jobs (1)
- # jobs-discuss (2)
- # joker (10)
- # leiningen (13)
- # off-topic (23)
- # other-languages (1)
- # pathom (24)
- # pedestal (5)
- # re-frame (6)
- # reagent (45)
- # reitit (3)
- # rewrite-clj (1)
- # spacemacs (2)
- # sql (23)
- # tools-deps (6)
- # vim (5)
is there anyway to disable parallel key timeouts? My usecase is that I want a delay computation, but reuse the request cache, so I would like to call p/entity-attr!
later. I put a lambda function with that call on a core.async channel to be processed later. If by that time the resolver has run I want to reuse it, otherwise calculate it on the spot, without duplicating the resolvers code. Sadly I get a key process timeout. What could I do differently?
@thenonameguy the parallel timeout is configurable, I'm not sure if you can disable it but you can make it a large enough number so it works, the default is 60s (just for context, this is kind of a last resource failing system, if nothing works this tries to guarantee the user will get some response after that time), you can change the value using environment data, you need to set :com.wsscode.pathom.parser/key-process-timeout 60000
(default value in this example)
about reusing the cache, one trick you can do is also send the cache atom in the env, example: (let [cache (atom {})] (parser {::p/request-cache cache} [...]))
this way you can hold to the cache after the request is done
Thanks! why can’t I just get
the existing (default) ::p/request-cache
from the env in the mutation I’m firing off this async lambda and pass it back in? It should be a reference type, no need to put it an ‘initial’ atom myself, I think
with the high timeout hack I could progress but p/entity-attr!
says that it’s unable to resolve my attr, while the entity has all the necessary inputs to do so
@thenonameguy its just that you don't have access to the env at the output level, the request cache is created one per request and then thrown away, so altough you can access during in-processing, there is no external access point for it, makes sense?
yes it makes sense, but I’m firing off this async stuff in a mutation, where env is in context
ah, in this case you can pull it, I'm not sure exactly how you are trying to do it, but by the description it seems correct, one thing to remember is that the case is based on resolvers, so what you cache is not the entity data but the resolver results, knowing that may help you
another thing, p/entity-attr!
uses ::p/entity
from the environment, so make sure that this data point has the inputs you need
Entity attributes #{:some/response} could not be realized
#:com.wsscode.pathom.core{:entity {:foo true, :java/inet-address #wp/inet "8.8.8.8"}, :path [[:java/inet-address #wp/inet "8.8.8.8"]], :missing-attributes #{:some/response}}
(pc/defmutation async-maybe-resolve [env params]
{}
(async/go
(async/<! (async/timeout 1000))
(some-side-effect (async/<! (p/entity-attr! env :some/response))))
true)
yeah, looks correct, I never tried from a mutation though, may be a bug, if you can get a minimum repro of the issue I can take a look