Clojurians Log v2

Hello Wilker (and the community here!). I'm trying to learn pathom (version 2 for now; looking forward to release of version 3) and have following question, a bit related to the project-query-attributes function mentioned a few days ago by Janos in this thread https://clojurians.slack.com/archives/C87NB2CFN/p1611604378029100?thread_ts=1611568102.021800&cid=C87NB2CFN project-query-attribute internally uses ::p/parent-query from env. I also found out that it's possible to access ::p/parent-query and use it to try to figure out, which of the outputs (fields) are actually being requested in that specific runtime situation. I wonder whether following approach is a good idea or it will hurt the query planner and explode in my face later. Let's say I have a resolver capable of returning :product/name, :product/price, :product/description etc. Let's say there's 20 such fields. Internally, the initial "naive" implementation executes SQL query that fetches all the 20 columns from the database table and returns them to pathom for further handling. This works fine, but it's obviously not very effective to always fetch all the columns' values when the client only asked for let's say :product/name and nothing more. In some of my simpler resolvers, I was able to peek into ::p/parent-query and make the SQL query dynamic and thus more efficient by only querying fir those columns that are actually required. But I'm not sure if it's a good idea or not. I have a feeling that it could break some internal functionality such as the filling the dots you often mention in your talks. What's the contract here? Should the resolver always return all the defined outputs, or is it ok for it to be a bit more clever and select just those fields which are requested by the actual runtime query? Sorry if it's explained somewhere in the docs and I just missed it.

hello Tomas, looking at ::p/parent-query is usually not enough, the problems is that maybe you need something that's not on query, but is a dependency that will show up at planning. this is what project-query-attribute tries to figure out. You can play around, but it works different in Pathom 3, Pathom 3 planner does way more, and also knows about dynamic resolvers (not really right now, I did some experiments, but this area needs more work, and I should start on this soon).

the way Pathom 2 does is quite inefficient, because each resolver that needs to know about this hidden dependencies has to do its own work

in Pathom 3, this is all done in a single pass during the planning phase

I hope to provide a friendly user API to create these kinds of resolvers