Clojurians Log v2

Hi all - quick question about EQL syntax. How does Pathom decide if a transaction refers to a mutation or a parameterized query (as far as I can tell, the syntax is the same). It is just up to the developer to make sure that mutations do not accidentally have the same names as resolver inputs?

mutations are always symbols

Ah, of course. 🤦 Thanks!

Will it be possible in pathom3 to link a remote pathom resolver? IE, system1 has a set of resolvers/mutations, and system2 has a set or resolvers/mutations and the ability to remotely call resolvers/mutations from system1?

yes, this is part of the dynamic resolvers feature in pathom 3

Is pathom appropriate for situations where you have a graph of interdependent calculations? So not just fetching a value from a DB, but calculating a value of an entity, possibly based on other calculated values? So in other words, could it be used as a data flow mechanism? I've been starting to read the docs and play around but haven't been able to determine yet if this is a good use case

yes, this is the main purpose of pathom 👍

I know ::pco/batch in p3 isn't documented yet, but I was trying it anyway and see some weird behavior where the batch resolver params contains duplicate values. Is this expected?

https://pathom3.wsscode.com/docs/resolvers#batch-resolvers

huh.. bit concerned as to how I missed that. thanks for sharing the link :)

no worries

at the top right there is also a search box

(defresolver foo [input]   {::pco/input  [:foo/id]    ::pco/output [:foo/prop {:foo/bars [:bar/id]}]    ::pco/batch? true}   [{:foo/prop "foo"     :foo/bars [{:bar/id 10}                {:bar/id 20}]}])  (defresolver bar [input]   {::pco/input  [:bar/id]    ::pco/output [:bar/prop {:bar/foo [:foo/id]}]    ::pco/batch? true}   (mapv (fn [v] {:bar/prop (str "bar-" v)                :bar/foo  {:foo/id 3}})         input))  (def test-env (pci/register [foo bar])) (p.eql/process test-env [{[:foo/id 1]                           [{:foo/bars [:bar/id :bar/prop {:bar/foo [:foo/id]}]}]}]) 

so if I run this query:

(process-query [{[:foo/id 1] [{:foo/bars [:bar/id :bar/prop {:bar/foo [:foo/id]}]}]}])

{[:foo/id 1] {:foo/bars [{:bar/id 10,                           :bar/prop "bar-{:bar/id 10}",                           :bar/foo {:foo/id 3}}                          {:bar/id 20,                           :bar/prop "bar-{:bar/id 20}",                           :bar/foo {:foo/id 3}}]}}

If I add one prop to the join:

(process-query [{[:foo/id 1] [{:foo/bars [:bar/id :bar/prop {:bar/foo [:foo/id :foo/prop]}]}]}])

why is that? it doesn't seem like the cardinality has changed?

your batch foo resolver is always returning a single item, by quick looking I think thats the problem

it needs to take the input size in consideration, and always return a list of same size as the input

oh, yes that's right. a bad example then sorry

I'm having an odd issue with pathom-viz it appears that when using the latest version, the application freezes when attempting to enter a join in the query editor. This happens as soon as the second vector (the one inside the map) is entered. This occurs whether the query is typed or pasted into the field. Responsiveness of the application can be restored by reloading it, but this does not fix the issue. While the app is unresponsive, the CPU usage also jumps considerably.

what OS are you in? using pathom 2 or 3?

Arch linux, pathom3. I tested both the Appimage and the Deb package

I managed to experience the same behavior you describe few days ago. I dumped my uncommited local git changes and found out it worked just fine again. So the problem must have been somewhere in my resolvers. I'll try to look if I still have that broken version in stash somewhere.

(ubuntu budgie, deb package)

in any case, no user code should freeze the app, I'm interested in figuring this one out, just don't have the time right now, but would be glad to try it later

@reilysiegel is this some code you can share? I would like to try reproducing on my end

or if you can't, a minimal reproduction case would be great

The code I'm using is in ReilySiegel/pod on GitHub, but it's not really in a great state at the moment (ie, no documentation, repl only, and the code structure is still changing). If you want to give it a try, init/halt functions are in com.reilysiegel.pod.server

I will work on a minimal reproduction as soon as possible, as that will likely be much easier for you to work with.

I believe I managed to find the minimal reproduction case of the freezing that happens in my case. When I define an ident-resolver that expects :product/id value on input and I also include :product/id value in ::pc/output, Pathom Viz freezes when I either copy-paste the query into its editor or when I type it manually. In that case it freezes in the moment when I type the opening bracket of the vector after ident (normally the code-completion popup would show). I have commented the :product/id with #_ in the example snippet. With this change, Pathom Viz doesn't freeze. If I uncomment it, restart Pathom Viz and re-connect by re-evaluating this whole namespace, Pathom Viz starts freezing again.

awesome, that seems an easy one to fix, I'll take a look at it later, thanks for the report!

Thanks for beating me to a minimal reproduction!

Sorry Reily if you wanted to to figure that yourself and I spoiled that to you 😉. It just happened that the exactly same issue as you described happened to me a few days ago and I wasn't sure why. Luckily I git-stashed that weirdly-behaving code, so that I can return to it later for further inspection of the issue.

found the problem in Pathom, fixed on master, also generated a new build for Pathom Viz: https://github.com/wilkerlucio/pathom-viz/tree/v2021.2.1

can you confirm this build works without freezing?