Fork me on GitHub

With pathom3, is there a way to access the options map that I pass into an operation inside of a plugin? I’d like to write a plugin that detects if a spec is passed in the options map and if so, validate the params before invoking the mutate. My thoughts are it could be used like below, and then the plugin would be responsible for validating the spec. If this isn’t possible, I could always wrap the defmutation with my own custom macro to accomplish this. Thanks!

(pco/defmutation my-mutation
  {::pco/spec ::my-mutation-spec}
  ;; If this is executed, I know that params fulfills the ::my-mutation-spec
  {::success true})


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
   (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 %)))))))})


In Pathom (2), is there anyway to reconstruct env after (or during) a mutation? This is primarily because we need to use a new Datomic DB value after the mutation has run. The pathom-datomic plugin also seems to use an old DB value after mutation is run.


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: 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


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)

🎉 3

> 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
  (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


Hello everyone! I am trying to setup Pathom3 with Pathom Viz. I started here: but I ran in the stacktrace: (short version)

Caused by: Could not locate com/wsscode/promesa/macros__init.class, com/wsscode/promesa/macros.clj or com/wsscode/promesa/macros.cljc on classpath.
Do I forget to import something?


@paul931224 seems like you are in an outdated version of pathom3, can you try the latest commit? (currently: d9a950c96f3fe3115a54679228dbf92c2ca06c9b)


My mistake, I had the good version a while ago, but somewhere in the process I must have overwritten it. Thank you very much! 🙂

👍 3