Fixed, the call had too many things, that ext point just gets env

something like this?

(defplugin no-attribute-errors-plugin
  {::pf.eql/wrap-map-select-entry
   (fn [original]
     (fn [env source ast]
       (when-not (= (:key ast) ::pcr/attribute-errors)
         (original env source ast))))})

I think you want https://pathom3.wsscode.com/docs/error-handling#lenient-mode

nah, what I want is the old default behavior before the error handling shakeup, i.e. no strict and no attribute-errors-plugin. so far my code seems to be ok

not available at this moment, I wonder if that should be a thing (completely silent errors)

can you tell more about the reason you like to keep that?

specifically, I make pathom calls to figure out what to put in a DB and that extra key was breaking things. in general it breaks an expectation I had that the output will always have a subset of the attributes of the query

I guess this is maybe a little un-clojurey where maps are supposed to be open, and you can assoc whatever keys and have consumers be agnostic to them, but it seems a lot harder to reach into say a nested entity after the query is done and recursively dissoc stuff than to just block it with a plugin

I also don't understand what I would ever do with the error keywords themselves, besides logging them, which would be done in a plugin

retries, different paths etc. seem like they'd just be done by pathom itself

gotcha, I also had a few issues with Smart Maps and that behavior, so I can understand that we just want to keep strict at times, I may add another flag to disable the error thing

my reasoning to have that baked in as default is because of distributed Pathom calls, it could get really bad if the default was to hide errors, than would become a nightmare for distributed pathom debugging

In my experience, the more work you can push down into the database (especially postgres), the happier you will be

option 1 would work but you'll be happier in a broader range of scenarios if you let postgres take on the bulk of the work

Thank you @U2845S9KL, I appreciate your advice.

hello calleb, I suggest you keep things simple as start, for db try to minimize the number of resolvers, so you minimize the number of round trips, so for example, to get the data from a user table, pull all the fields (but no relations) as a single resolver, use other resolvers for the relation traversing

there are ways you can optimise this in the future, you can ask pathom for example about which fields that resolver is supposed to cover (at running time, this is based on the user query and dependencies), so you can optimize the DB request to reduce the fields

in general, its not nescessary though, given for the DB the add of fields in the same row are usually very snappy, but I like to let you know it can get optimised if needed be (maybe there are 100 fields and most queries just cherry pick a few, in this case the optimisation makes more sense)

I think it's worth mentioning #walkable I don't think that you can directly use it because it is still in development but it has some nice ideas.

https://github.com/walkable-server/walkable/

Walkable is great, but it isnt compatible with any other pathom stuff at the moment, it works only as standalone, that may change, I recently got progress enough on dynamic resolvers that we can start playing with that now