Clojurians Log v2

Interesting, I didn't know you could use a :where in the input section, is this documented somewhere? Can't immediately find it. This appears to work correctly, although it's not an answer to your question.

(pco/defresolver company-problems [env {:company/keys [locations]}]
  {::pco/input [{:company/locations [:location/deleted
                                     :location/problems]}]
   ::pco/output [:company/problems]}
  {:company/problems
   (reduce
     (fn [acc {:location/keys [deleted problems]}]
       (cond-> acc (not deleted) (+ problems)))
     0 locations)})

I think it's that the :where is just something we chose to put in the params and our resolver can choose to look at the params and do what it wants with them. So it's not about documenting that :where can be in the input section, but rather that you can put whatever you want there and then act on it however you choose in your resolver.

Yes, the above suggestion of not using params and doing the filtering in the resolver that is aggregating avoids the problem. It doesn’t address the issue that if parameters are meant to effect what a resolver returns, then if two nodes of the same resolver with the same inputs but different parameters are merged, you are changing the output of one or both nodes. That isn’t an optimization, but a mutation of the computation.

Thanks for taking the time to look at it @wilkerlucio! If there is any way I can be helpful please let me know. I am happy to contribute time and effort to pathom.

I am also interested in the outcome here, params and caching issues in pathom3 make me nervous

hi folks, thanks for bringing it up and the example @smniel, I plan to have a look at it this weekend

I have been diving into the code more and it appears the run graph and the optimizer are not the problem as much as how the data is stored as the entity-tree is built up. It was pretty straightforward to update the requirements for nodes to be combined to include having the same parameters. However, the results of both calls to resolvers are merged into the entity tree with no indication of which parameters were used. In order to be able to avoid one being merged over the top of the other, the results would need to be stored in a way that separates results calculated with different parameters, and how to then populate resolver inputs and overall results with this being taken into account. I am thinking through how this could be done. @wilkerlucio Is this an idea that you are interested in entertaining in pathom?

@smniel hello, I finally got to look, and your analysis is on spot. but it does hit an important heuristic of pathom, that is: for each entity, every attribute can only be resolved once. what you suggesting would imply to resolve :company/locations twice for the same entity, and that's a no-go. this is done to help reducing complexity on both planner and runner. my suggestions is to make the location load an external function that you share across resolvers, instead of trying to share an attribute that might be resolved multiple times

that said, I think it as issue that it goes unrepported to the user, maybe we should fail during planning to ensure the user gets aware of the conflict