Fork me on GitHub

lately we have been thinking about a way to create something like auto discovery or some kind of documentation for params. Now, It’s hard for clients to know what parameters can be used. initially we are just including the parameters as part of defresolver.

(pco/defresolver a-resolover
   {::pco/output [...]
    ::pco/params [...]})
with the hope that later we could generate somekind of docs from it. does this make sense? would it be worthy to include params as metadata in the index?


::pco/params as any other :custom-key that you put in that map will be included on indexes Tools like pathom-viz can already show it.


awesome 🙂 didn’t know that 🙂


one more thing 🙂 what’s the best way on pathom,3 to short circuit the execution of a particular attribute? Currently facing some performance issues when there is an optional attribute in the output.


can you pinpoint what is getting slow? planning? running? have you checked with Pathom Viz?


@U066U8JQJ yes, we know what’s causing the slow down. Imagine the following:

;; spec
(s/def ::a (s/keys :req [:a/code :a/id])
                   :opt [:a/ref] ) ;; ref is optional

;; data
[{:a/id 1 :a/code "x"} {:a/id 2 :a/code "y" :a/ref "y2}]

(pco/defresolver all
   {::pco/output [:all [:a/code a/ref :a/id]]}
 ...some io )

(pco/defresolver by-id
   {::pco/input  [:a/id]
    ::pco/output [:a/code a/ref]
    ::pco/batch? true }
 ...some io )

(pco/defresolver by-code
   {::pco/input  [:a/code]
    ::pco/output [:a/code a/ref]
 ...some io )

with the eql
[{:all [:a/code :a/ref]}]
Pathom now executes all the resolvers trying to find an :a/ref for [:a/id 1] if :all is large enough we get slowdowns. so we thought that the solution is to tell pathom to stop trying to search for the attribute after the first resolver is executed as we already know that the attr will not be found.


so far to avoid the problem what we did is to create a new batch resolver to solve any optional parameter. so we remove :a/ref from the existing resolvers and created a new batch resolver

(pco/defresolver ref-resolver
   {::pco/input  [:a/id]
    ::pco/output [:a/ref]
    ::pco/batch? true }
 ...some io )
not sure however if this ideal


I'm still not getting what is the issue here, and what you expect to be different, can you send images from pathom viz where you can highlight what is slow?


(and in general, if batch is getting faster results, use it)


i will prepare something from viz but going back to the above: when running:

[{:all [:a/code :a/ref]}]
The all resolver would return [{:a/id 1 :a/code "x"} {:a/id 2 :a/code "y" :a/ref "y2}] already at this moment the programmer could know that [:a/id 1] doesn’t have a ref. however pathom will try to find it so it would go and run by-id with inpunt [:a/id 1] and will not find the ref, so it will go an execute next resolver by-code with input [:a/code "x"] because this is not a batch resolver it could execute many times. (one time for each entry that doesn’t have a ref)


on pathom 2 the first resolver could return

(with-meta [{:a/id 1 :a/code "x"} {:a/id 2 :a/code "y" :a/ref "y2}] {::p/final true})
so the other resolvers wouldn’t be executed


gotcha, is about the nested thing


I was confused because you mentioned OR, so I though was something inside the internal processing of a specific graph


ok, I think its time to get ::final in Pathom 3, I can do that later today


🙂 sorry for the confusion.


no worries 🙂


@U0J6U23FW ^::pco/final [...] now works on Pathom 3 master (also for maps, etc...)

🧙 3

oh wow you are fast man!

😎 3

@U0J6U23FW thank you for the sponsoring! 😄

👍 3

pathom2 had a ^:final metadata that says to parser "do not enter this structure. Not sure about pathom3