Fork me on GitHub

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. facepalm Thanks!

Reily Siegel04:02:01

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?

✔️ 3

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

Reily Siegel13:02:12

Is there an approximate timeline for.this feature, or is it still being planned?


cant promise times, Im finishing some docs adjusts, dynamic resolvers is the thing I want to work next, my guess is to have something in about 1 ~ 2 weeks

Reily Siegel14:02:56

Thanks for the rough estimate! Sorry to sound a bit like a nag, but I am trying to use pathom3 in a (non-commercial) project, and it has been great to work with so far! Thanks for all the work you put in!

🙏 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 👍

👍 3

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?


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


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]}]}]}])
I get this result:
{[: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}}]}}
looks good


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]}]}]}])
I get Batch results must be a sequence and have the same length as the inputs.


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

Reily Siegel18:02:30

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?

Reily Siegel19:02:13

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

Tomas Brejla19:02:38

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.

Tomas Brejla19:02:06

(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


@U6NJBB596 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

Reily Siegel19:02:50

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

Reily Siegel19:02:54

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

👍 3
Tomas Brejla21:02:28

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!

Reily Siegel21:02:53

Thanks for beating me to a minimal reproduction!

Tomas Brejla21:02:22

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:


can you confirm this build works without freezing?

Tomas Brejla00:02:32

Seems to have fixed the issue for me :thumbsup: 👏 Thanks!

🎉 6

Nice !!! i was having the same issue and couldn’t really find a reason! The new build solves the problem !!!

❤️ 6

Thank you !!!