@wilkerlucio I was working with @dansudol on getting unions working with connect…it looks like pathom is seeing union queries as recursion limits instead of unions.

whenever you get time, perhaps you could look…we’ll try to narrow it down further

@tony.kay did you figure it out?

we never did Wilker, we were hoping you had an idea

sure, can you send a minimal case of what you are trying so I can reproduce here?

its basically where you have an entity like company which has company/id and this company entity ( using datomic ) has a bunch of attributes, and lets say one of them is company/thing

let's say company/thing holds pointer to different types of entities like pots or pans

so if i wanted to query for companies and their thing i would say

{:company/id [:company/thing {:thing/pot [:color :name] :thing/pan [:size :name]}]}

because i want to get maybe a thing/pot ( with its attributes ) or thing/pan with different ones from the company/thing reference

with fulcro we found that we could compose this query , but pathom did not want to parse it

@dansudol thanks, but I mean some full example trying to use with pathom and the results your are seeing

I ask because I do use the union feature on a daily basis, so I wonder what you guys may be doing different

I not sure how to show more @wilkerlucio because the query we were doing was just exactly like I put above, and we never even got to the resolver stage, pathom just said "no thanks pops I not even looking at that query" with an exception with the "recursion limits" message

if what I posted above is not proper union query then let me know, or maybe you have something going on in your parser ? that is different than mine .. maybe our parser setup needs some special sauce ?

i can screen share if it is easier to see the full picture because i know just sending a query is kinda lame ( but not sure how else to show it)

I mean na example creating a parser, the resolvers and triggering a query, so I can run it and see the same thing you are seeing

a minimal reproduction also helps to drill down the potential problem

let me write one real quick here

in our case it is easy because the resolvers never were touched .. the parser refused to run the query

the query you sent me is the exact query you are issuing?

(defn get-parser []
  (let [real-parser (p/parallel-parser
                      {::p/mutate  pc/mutate-async
                       ::p/env     {::p/reader               [p/map-reader
                                                              pc/parallel-reader
                                                              pc/open-ident-reader
                                                              p/env-placeholder-reader]
                                    ::p/placeholder-prefixes #{">"}}
                       ::p/plugins [(pc/connect-plugin {::pc/register (vec (vals @pathom-registry))})
                                    (p/env-wrap-plugin
                                      (fn [{:keys [conn] :as env}]
                                        (cond-> (merge env {:config config})
                                          (not conn) (assoc :conn (get-conn)))))
                                    (preprocess-parser-plugin log-requests)
                                    (p/post-process-parser-plugin p/elide-not-found)
                                    p/request-cache-plugin
                                    p/error-handler-plugin
                                    p/trace-plugin]})
        ;; NOTE: Add -Dtrace to the server JVM to enable Fulcro Inspect query performance traces to the network tab!
        trace?      (not (nil? (System/getProperty "trace")))]
    (fn wrapped-parser [env tx]
      (async/<!! (real-parser env (if trace?
                                    (conj tx :com.wsscode.pathom/trace)
                                    tx))))))

(defstate parser :start (get-parser))

that is our parser setup

and we actualy tried something exactly like that ( that same form ) and what was nice ( so to speak ) was that we could do any union looking query ( even if the attributes were non existent like

{:company/id [:company/thing {:noodle [:w :blah] :rice [:a :b]}]}

if we ran anything that looked like union .. pathom would not parse it

because a map is not a valid query

queries must be vectors

this can't be your root

so how does union work then because fulcro sets up a union query to look like that ( according to Tony ) and our exeriments yesterday

that can be a join of something, but can't be the root

eg: [{[:some/join 123] {:branch/a [...] :branch/b [...]}}]

sure sure .. you mean i should have typed

[{:company/id [:company/thing {:noodle [:w :blah] :rice [:a :b]}]}]

that's wrong too

aaah .. yeah .. i see what you mean

but your assuming we know the join id ( which we don't )

doesn't need to be an ident join

but must be a join

[{:named-join {:branch/a [...] :branch/b [...]}}]

right .. exactly

{:company/id [:company/thing {:noodle [:w :blah] :rice [:a :b]}]}

this is what we were doing minus the []

[{:company/id [:company/thing {:noodle [:w :blah] :rice [:a :b]}]}]

I just got this example working here:

but assume the vector was there

(quick-parser {::pc/register [(pc/resolver 'thing
                                  {::pc/output [{:get-thing [:a/id :b/id]}]}
                                  (fn [_ _]
                                    {:get-thing {:a/id "A"}}))

                                (pc/resolver 'a
                                  {::pc/output [:a/name]}
                                  (fn [_ _]
                                    {:a/name "A name"}))

                                (pc/resolver 'b
                                  {::pc/output [:b/name]}
                                  (fn [_ _]
                                    {:b/name "B name"}))]}
    '[{:get-thing
       {:a/id [:a/name]
        :b/id [:b/name]}}])

quick parser is just a helper I use for testing, it generates a basic parser and run it

in case you need for details:

(defn quick-parser [{::p/keys  [env]
                        ::pc/keys [register]} query]
     (let [parser (p/parallel-parser {::p/env     (merge {::p/reader               [p/map-reader
                                                                                    pc/parallel-reader
                                                                                    pc/open-ident-reader
                                                                                    p/env-placeholder-reader]
                                                          ::p/placeholder-prefixes #{">"}}
                                                         env)
                                      ::p/mutate  pc/mutate-async
                                      ::p/plugins [(pc/connect-plugin {::pc/register register})
                                                   p/error-handler-plugin
                                                   p/request-cache-plugin
                                                   p/trace-plugin]})]
       (async/<!! (parser {} query))))

man .. this is neat parser trick

run examples

this is neat o .. i will try and let you know

(noticed I changed the get-thing resolver across the runs to demonstrate the branch selection)

what you find new there?

yes

maybe you declared resolver like

{:get-thing [:a/id :b/id]}

with ::pc/out

so maybe pathom was able to recognize ?

yeah, you need that, otherwise pathom can't know what to do (or how to auto-complete)

there are other ways do it, its valid to also do in a flat way

i think we were missing that .. 80% sure

for that

::pc/output [{:get-thing [:a/id :b/id]}]

cool, I hope that can make things move for you

if not, lets keep on it 🙂

should i list all the attributes besides id ? like [:a/id :a/name :a/blah :b/id. .etc ]

for sure thanks W .. i will run this and check it

list all the things you intend to return from this resolver

got it 🙂

The problem was with the output spec. I assumed it should look like a union, but your example cleared it up: a vector of possible IDs instead of a union query in ::pc/output

makes sense, I just assumed the EQL notation was what was always used in output

yeah, that's a good point to clarify in the docs, and we can probably support the union syntax as well, a simple impl could flat it out at definition time

I'm taking notes on things I want to improve on the new docs (that are in progress as of now), that's surely a good one to add