This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-26
Channels
- # asami (3)
- # babashka (3)
- # beginners (45)
- # boot (3)
- # calva (6)
- # clojure (26)
- # clojure-dev (16)
- # clojure-europe (15)
- # clojure-norway (6)
- # clojure-uk (6)
- # clojurescript (34)
- # community-development (4)
- # conjure (3)
- # datascript (4)
- # datomic (4)
- # emacs (21)
- # events (1)
- # fulcro (16)
- # graalvm (5)
- # jackdaw (1)
- # kaocha (5)
- # lsp (74)
- # malli (8)
- # nbb (37)
- # off-topic (50)
- # pathom (5)
- # reagent (19)
- # ring (1)
- # shadow-cljs (60)
- # sql (3)
Are recursive calls to p.eql/process
supposed to work?
Ok. Should I purge the env with the current plan if I do so?
Oh, I see. I had this cache/context issue in pathom2. By doing this, we can discover dynamically which keys pathom3 create in the process
(def keys-to-dissoc
(let [env (pci/register
[(pco/resolver `a
{::pco/output [:a]}
(fn [env _]
{:a (set (keys env))}))
(pco/mutation `b
{}
(fn [_ _]))])
init-ks (set (keys env))]
(remove init-ks (:a (p.eql/process env [:a])))))
Then you can call (p.eql/process (apply dissoc env keys-to-dissoc) ...)
Not an elegant solution.
In theory, I think that nested process
calls should be able to share indexes/caches/plans.
What is the actual problem that you are having?Well when I call process
in a resolver, the output I get is different (empty) from when I get when I call that same query outside the resolver. It works when I pass the env before that resolver call.