Clojurians Log v2
pathom
@markaddleman fixed for viz elements just pushed up
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 [...]})
::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 🙂
thanks!
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.
@wilkerlucio 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]}]: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 )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]}]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})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 🙂
@jmayaalv ^::pco/final [...] now works on Pathom 3 master (also for maps, etc...)
1🧙tests with examples at https://github.com/wilkerlucio/pathom3/commit/58b5585bc99a83661a37f6225a61290b647cb810
oh wow you are fast man!
1😎pathom2 had a ^:final metadata that says to parser "do not enter this structure. Not sure about pathom3
Hi - I loaded up my OIR index and my query into the tool. I'm not really sure what I'm looking at.
When I execute the failing query, I get an indication that the final node is unreachable.
However, when I change the query to return the problematic attribute, it computes the plan just fine and returns the correct result
Should the "Log Graph" button do something? When I click it, the console displays a (presumably ClojureScript) object but it does not look intelligible
@markaddleman can you check if you are in pathom latest? because the viz uses its own compiled version of pathom to compute the plan there, I wonder if you missing some fix
the log graph, yeah, was a oversight, because in dev logs fine, but on the site its not usable
I can fix that to log a pr-str of the graph
I'm using pathom commit 6b2282e6dc4cfabd449cf7837fcefdd1c9b09891 . I'm not sure how to get the version of Pathom Viz but I'm almost certain it's the latest compiled binary from github. btw, the exception that I'm getting is from Pathom, not Viz
can you pinpoint what is getting slow? planning? running? have you checked with Pathom Viz?
ok, I think its time to get the stepper to the next level
currently using that view from embed has an issue, actually more than one: 1. it runs using the internal pathom, not the client pathom, and that can cause confusion 2. this version only looks at index-oir, which is not complete, it don't contemplate the nested queries (and I believe that may be the case you are hitting)
the next level is to integrate that properly in Pathom Viz, some sort of button to debug a query, that can leverage all index, and run in your environment
that would be great