Clojurians Log v2

@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]}]

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]}]

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...)

tests with examples at https://github.com/wilkerlucio/pathom3/commit/58b5585bc99a83661a37f6225a61290b647cb810

oh wow you are fast man!

@jmayaalv thank you for the sponsoring! 😄