Fork me on GitHub
#pathom
<
2022-08-26
>
wilkerlucio02:08:40

hello folks, I made a release yesterday that was broken, since then I wanna be more careful with the new optimisations, they are specially useful if you are using dynamic resolvers, they may considerably reduce the number of dynamic calls. but even if you are not using dynamic resolvers and like to help mature those optimisations, if you have some large graph, I really appreciate if you can test your queries in it using the new optimisations, and report any problem you may find 🙏 if you like to help testing, bump to latest and add :com.wsscode.pathom3.connect.planner/experimental-branch-optimizations true to your env, this flag will enable the new branch optimisations

👍 1
Hukka07:08:27

I haven't really used pathom viz. Should I be reading these graphs differently than just normal boolean logic? In the left side, the AND node requires either ab1 or ab2 via the top two branches. But on the right side, they aren't; any leaf node will do.

wilkerlucio13:08:43

this graph is an execution graph, its tunned to minimize the work of the runner, the runner will walk this graph from the root, executing the nodes on the way, its important to know the difference between the arrows, the oranges are the branches and run first, the black is "run next", and will run only after all the orange ones run (including their children), to understand whats happening its good to understand the initial query, and see what the graph is doing, the query was: [:a :b :c], where there is 2 resolvers with output [:a :b], and two resolvers with output [:c] (both depending on [:a :b]). considering that, the graph on the left has and AND with 3 branches, one for :a, one for :b, and one for :c, what the optimizations is doing is checking that, for example, :a and :b have the same exact nodes, so we dont need that repetition, and we can merge those. similar, for the :c computation, both OR nodes have the same duplicated :a and :b requirement, there it needs to merge also the thing that runs after each of the OR paths (that lead to c1 and c2), in the end it generates the graph with the minimum amount of nodes, because both ab1 and ab2 are able to realize both :a and :b, same for :c, we only need one of c1 or c2 to get it. makes sense?

Hukka14:08:21

Took a couple of tries, but I think I do

wilkerlucio15:08:25

sorry, all orange must run for AND nodes, in case or OR node, each orange arrow is a possible path

Hukka16:08:39

Yeah, the OR and AND are over the orange inputs, resulting to all black outputs

👍 1
sheluchin13:08:03

It looks like the build for v2022.08.26-alpha failed and I'm also getting some Pathom errors when using RAD reports. It's complaining about Insufficient data calling resolver even when the data is obviously there. This is without enabling the experimental stuff.

wilkerlucio13:08:50

hello @UPWHQK562, can you make some repro that I can try? also, have you checked the plan, it looks an error in planner or runner?

sheluchin15:08:54

Good morning @U066U8JQJ.

(comment ; pathom3 v2022.07.08-alpha
  (p.eql/process {}
                 {:a :_}
                 ['({[:a 42]
                     [:a
                      {[:x 99] [:x]}]})]))
=> {[:a 42] {:a 42
             [:x 99] {:x 99}}}

(comment ; pathom3 v2022.08.26-alpha
  (p.eql/process {}
                 {:a :_}
                 ['({[:a 42]
                     [:a
                      {[:x 99] [:x]}]})]))
=> ExceptionInfo
Execution error (ExceptionInfo) at com.wsscode.pathom3.connect.runner/processor-exception (runner.cljc:901).
Graph execution failed: Required attributes missing: [:a] at path [[:a 42]]

sheluchin15:08:44

The shape is just repro of how RAD report queries are shaped.. something like this:

['({[:item/id 1]                              
    [:item/id                                 
     {[:com.fulcrologic.rad.report/id         
       :com.example.ui.reports/ItemsReport]   
      [:com.fulcrologic.rad.report/id]}]})])) 

wilkerlucio23:08:20

@UPWHQK562 thanks for the report, the issue was related to change to support ::wrap-merge-attribute (not related to planner changes) with idents, fixing it now

wilkerlucio23:08:24

@UPWHQK562 can you please try sha 9fd82ed868303f94b385ba7411b3107c4a76895d and confirm it works in your scenario?

🙏 2
sheluchin10:08:58

@U066U8JQJ Yep, looks like that fix solves the issue. No more errors in the REPL. Thank you.

wilkerlucio02:08:40
replied to a thread:

hello folks, I made a release yesterday that was broken, since then I wanna be more careful with the new optimisations, they are specially useful if you are using dynamic resolvers, they may considerably reduce the number of dynamic calls. but even if you are not using dynamic resolvers and like to help mature those optimisations, if you have some large graph, I really appreciate if you can test your queries in it using the new optimisations, and report any problem you may find 🙏 if you like to help testing, bump to latest and add :com.wsscode.pathom3.connect.planner/experimental-branch-optimizations true to your env, this flag will enable the new branch optimisations

👍 1