yes you can, its a bit different for mutations and resolvers, but both are accessible

in the wrap-mutate you get the AST, you can use the :key there to know the mutation name, use that to lookup into ::pci/index-mutations

a mutations is a record, you can get the options map with pco/operation-config

in the case of a resolver what you get is the node, the node has an ::pco/op-name, you can use that to find the resolver in the ::pci/index-resolvers

for convenience, use the helpers pci/mutation-config and pci/resolver-config

awesome, that helps a lot (and is awesome)! thanks for your guidance!

I would suggest name that something like param-spec to make it cleaner, and better to use your own namespace for it (to make the inference of ownership easier)

good call! i agree that name is cleaner. got it working as well! thanks again!

(p.plugin/defplugin params-spec
  {::p.plugin/id `params-spec
   :com.wsscode.pathom3.connect.runner/wrap-mutate
   (fn [mutate]
     (fn [env {:keys [key params] :as ast}]
       (let [{:keys [params-spec]} (pci/mutation-config env key)]
         (when (and (some? params-spec) (not (s/valid? params-spec params)))
           (throw (ex-info "Invalid params" params
                           {:message (s/explain-str params-spec params)})))
         (mutate env (cond-> ast
                       (some? params-spec)
                       (update :params #(st/select-spec params-spec %)))))))})

trying to remember if that works, but try returning a modified env in the key ::p/env in the return of the mutation data

Just saw that here: https://blog.wsscode.com/pathom/#updating-env Thanks! Going to check if this also works for mutations.

Thanks @U066U8JQJ that worked :i_love_you_hand_sign::skin-tone-2:

Yep, that worked!

::p/env only work on reads or in mutations too?

works on reads

@U2J4FRT2T https://blog.wsscode.com/pathom/#updating-env

no feature for that in pathom 3, maybe that will get add, but I remember having problems of reliability with it, gotta put some hammock time on it

like in some situations the env could leak out, I wanna Pathom 3 to be safer on that

@U06B8J0AJ I work on an pathom app for 1+years now. Now I'm facing some issues because I let my db value at env We are moving the db into input

you could also keep db as something mutable in env (as an atom) and update it anytime you see fit (for sync process this should be fine, for parallel not so much)

@U2J4FRT2T one thing to be careful about db as input is to be sure you are not leaking it out

(or allowing the users to request teh full db on their queries)

in Pathom 3 that's quite easy (and efficient) to do, using wrap-map-select-entry, in Pathom 2 its doable, but needs to walk the output to be sure (still easy, but not efficient)

> works on reads Whether intentionally or not, it works on mutations too!

We're currently doing this after a TX to Datomic,

{…
 ::p/env (refresh-env! env db-after)
 :tempids tempids}

Inserting the updated DB, extracted from the response from Datomic (both for pathom-datomic and our on part of env). It works well.

> you could also keep db as something mutable in env (as an atom) and update it anytime you see fit (for sync process this should be fine, for parallel not so much) We did this at first, and it was not great. Particularly, pathom-datomic didn't follow suit, but also it's fairly unergonomic. It's easy to get wrong.

with some cache issues, but it really work

(let [register [(pc/resolver `b {::pc/output [:b]}
                             (fn [{:keys [b]} _]
                               {:b b}))
                (pc/mutation `a {}
                             (fn [env _]
                               {::p/env (update env :b inc)}))]
      parser (p/parser {::p/plugins [(pc/connect-plugin {::pc/register register})]
                        ::p/mutate  pc/mutate})
      env {:b         0
           ::p/reader [p/map-reader
                       pc/reader2
                       pc/open-ident-reader
                       p/env-placeholder-reader]}]
  (parser env `[{(a {}) [:b]}]))

In our case, we only needed it on mutations, as queries are the opposite: we absolutely don't want different parts of the query to use different DBs (or, the DB at different times). That can return some real frankensteinish results.

And for pagination, we want to be able to keep the DB timestamp stable until the user decides to refresh the query.

did something similar for one of my first plugin attempts, went the atom route