I am looking for some help I am currently fighting with joins in pathom, I am running pathom 2.2.0-beta14. And I am trying the following:

(defresolver `entity-autocomplete
  {::pc/output [{:entity/autocomplete
                 [::autocomplete/group-key
                  ::autocomplete/group-entity-type
                  {::autocomplete/items {:entity.type/company [:company/id :company/name :company/website :company/description]
                                         :entity.type/contact [:company/id :contact/name :contact/email :contact/description]}}]}]}
  (fn [{:keys [ast] :as env} _]
    {::pc/env (assoc env ::p/union-path :entity/type)
     :entity/autocomplete search-results}))

(is (= (test-parser env
             [{'(:entity/autocomplete {:filter-value "Av"})
               [::autocomplete/group-key
                ::autocomplete/group-entity-type
                ::autocomplete/items {:entity.type/contact [:contact/id :entity/type]
                                      :entity.type/company [:company/id :entity/type]}]}])

           [{::autocomplete/group-entity-type :entity.type/company
             ::autocomplete/group-key :atlas-crm.domain.autocomplete.group-key/search-results
             ::autocomplete/items [{:company/id 1
                                    :company/name "Avisi"
                                    :entity/type :entity.type/company}]}]))

This diff shows it more clearly

hello @mitchelkuijpers, long time 🙂 what reader are using you using? the regular pc/reader?

@mitchelkuijpers I just noticed your query is missing the {} around the ::autocomplete/items join

Oh goodness

Thank you so much!

and the output should be a map insteadf of a vector, but I guess that will show up quickly there now, hehe

@wilkerlucio We are using pc/reader but I as peeking into parallel reader

cool, if you are going from the serial parser you have some things to check during the migration

I'm gonna write more about it, but the main thing is sync vs async

Nice this totally fixes it! We looked at it with 3 persons but no-one noticed 😛

Can the parallel reader do smarter batches? Because then it would be very interesting

people migrating from async parser will have no work do to, but if you wrote plugins or you do recursive parser calls in your resolvers, then you need to change some things to support async because the parallel is async

it can do the same batch the serial does, is that one or you are thinking on something different?

Ah we don't do recursive parser calls we just use connect

Not sure, we will do load-testing next week so we might try out both and report back if the parallel gives a big speedboost

I would guess so

cool, another thing to watch out is the ::pc/env thing, that just doesn't work on parallel due to how it process the query, I'm replacing it with ::p/env that will work in a lower level and should work to port, but I have to verify if it's working in all expected cases

Ah ok would be interested in that. But we acdtually added it to the env-plugin: ` ::p/union-path :entity/type `

at same time, for unions we have a different standard solution as well, that I think fits more easely in the connect way

Ah ok would be interested in that. But we actually added it to the env-plugin:

::p/union-path :entity/type

oh, if you have that static, then all good

Yes we do

And if we need more options I would make that a function

in previous versions if you didn't provide the ::p/union-path then it would raise an error on unions, but that changed

Yes I noticed, very nice change

now the default is a fn that tries to find the union branch as a prop on the entity

easier to code than explain XD

(defn default-union-path [{:keys [query] :as env}]
  (let [e (entity env)]
    (if-let [path (some->> (keys query)
                           (filter #(contains? e %))
                           first)]
      path)))

Ah nice, that is fancy

I gotta to but thank you so much for spotting the derp

no worries, glad to talk to you again, its been some time