I have the same use-case and pass {:db (atom (datomic/db datomic-conn)), :datomic-conn datomic-conn} as env. That way I can update :db with :db-after during the mutation and use @db in the resolver.

Does the return of the mutation updates the env? I'm not following how what you are suggesting works.

@U05476190 do you use PathomViz? if you do, how do you remove the datomic data from your env before sending it to Viz?

No, at the moment I'm using P2 and Fulcro inspector (which shows EQL and some perf stats), but not the newest PathomViz which shows env, etc. But I've been following your thread about cleaning up the env data @U0509NKGK and I'm looking forward to a clean approach (and finally getting PathomViz setup and migrating to P3).

I will say the problem seems similar to issues in P2 with it returning indexes that were not serializable, where we just made a custom resolver middleware that dissoc the pathom-indexes, etc.

@U05094X3J - in the mutation, you want to (reset! (:datomic-db env) db-after) as a side-effect, and then return whatever you normally return from the mutation; and in the resolver you want to use (deref (:datomic-db env)) as the DB you pass into queries. Since you are storing it as (atom (datomic/db datomic-conn)) the atom takes care of the coordination; and Pathom guarantees read-after-write semantics for "first run mutations, then run resolvers"

(Going afk now, but hope that makes sense)

it does, ta!

Oh, I missed the atom part. This helps a lot, thanks!

In Pathom 2 you can return a new env in your mutations: {:com.wsscode.pathom.core/env (assoc env :db db-after)}

Interesting… #TIL

Is there something like this env update on pathom3 @wilkerlucio ?

I'm a bit reluctant to add this back, the reason is that I've seen a couple of cases where you end up leaking your env out by accident, and that is really bad, so I hater find another way to handle those cases, the atom is a valid one that's less risky

Ok, thank you!

I recoomend use ::my-app/db as a "input", not as a env