pathom engine should be able to process.

but i don't think that it make sense for EQL's. I would classify as a "undefined behavior"

Is it bad form, even if technically possible? Ah, got it. Thought so. So if you want to run a bunch of mutations in series you just make a regular function that just calls p.eql/process on different mutation vectors or just use one vector with multiple mutations if there is no logic to perform between mutations, right?

something like [(batch-mutation {:mutations [(create-user {}) (login-user {})]})] ?

I was thinking either:

(p.eql/process env [(create-user {}) (login-user {})])

(p.eql/process env [(create-user {})])
;; use result from first mutation somehow
(p.eql/process env [(login-user {})])

I would do a single [(create-user-and-login {})] mutation

Why? Then you lose the ability to use those components separately.

you can keep the 3 operations

If you do that you duplicate the logic from create-user and login-user, no?

you can reuse at funciton level. What the frontend will do if [(create-user) (login)] fail? it will test to see if it failed at create-user or at login ? then decide if will repeat both of just one?

create-user-and-login can rollback the user creation if the login fail.

I see your point. Hmm, defmutation is just a wrapper around defresolver, right? In that case, I guess mutations can be called as regular functions the same way resolvers can? https://pathom3.wsscode.com/docs/resolvers/#invoking-resolvers

being on the server, you can even do things like this:

(defmutation create-user-and-login [ctx params]
  (let []
    (sql/with-rollback
      (p.eql/process ctx `[(create-user ~params)])
      (p.eql/process ctx `[(login ~params)]))))

Yes, I guess if you use the mutation as a function you skip Pathom's tree traversal and accompanying trace in case of an error. Good point.

one thing to consider if you call the mutation directly is that you also dont get the mutation join processing (if you have a query to run over the mutation response)

Thanks @U066U8JQJ, I hadn't considered that. Seems like a fair tradeoff to make in some cases. Good set of options here.

yeah, calling the mutation directly is really just like calling a regular fn, with a fixed interface (`env params`)

its a convenience, and if your usage makes sense, go for it 🙂