Current idea: Use superlifter/add-bucket! to create a new bucket every time we need to context-switch, but there will be lots of buckets to sync.

We've just made our (datomic) db value a part of the identity of our fetch records

Yes, that’s our use case as well. Datomic transact function give us a db-after value after transaction, so we need to use that as a basis in all of the fields nested below.

We have a db value in the lacinia context, which we update at the end of a mutation by passing a new context to lacinia using resolve/with-context.

Yup, assuming there are multiple mutation transaction running concurrently, thus returning multiple db value, each with different T. How should the data-fetching function (running on a thread pool) know which db (= T) to use?

I think it's not possible to run multiple mutations in a single graphql document if you're using lacinia

Well…… I’m not so sure about that……

Let’s go back to the original question. How do you update superlifter’s context? Presumably you could transact, get a new db, somehow update superlifter’s context, and finally use resolve/with-context to change lacinia’s context.

> Well…… I’m not so sure about that…… I checked, My original statement is not true (any more?) according to [the docs](https://lacinia.readthedocs.io/en/latest/mutations.html). Either way; they're executed serially. > How do you update superlifter’s context I just checked our usage; and we use urania-opts to initially set a context using an interceptor. In our resolvers we use (with-superlifter context before resolving anything, where context is the first argument of our resolver. I think this is enough to get it to work. Most of our resolvers return stubs and require the superlifter so our approach would rely pretty heavily on this.

How do you pass a db to your data fetcher (i.e. superfetcher)? 1. via superlifter’s :urania-opts 2. via superfetcher’s identity (s/def-superfetcher FetchFoo [id db] ...) 3. via a shared atom And how do you change to a new db after a transaction?

(same company as thumbnail) We don’t use the macro that superlifter offers; we just have simple defrecords implementing the DataSource protocol:

(defrecord MyFetcher [db id]
  u/DataSource
  (-identity [_] [(db->cache-key db) id])
  (-fetch [_ env] ...))

(defn my-fetcher [db id] 
  (->MyFetcher db id))

So; kinda like your option 2, but without the macro

IOW, to go back to your original question, we dont update the superlifter context; database values are not in the superlifter context for us

We do update the lacinia context with a new db value, and we use that to create new fetchers (as show above)

Meaning the selection below a mutation uses the db-after value of the datomic transaction

Does that help?

Got it. It makes so much sense now. We’ve started with similar pattern (using the macro), but somehow the query won’t get batched. Maybe there is something wrong with our implementation, but it works if you implements a BatchedSource, right?

😅 I forgot we ditched the superlifter macros, thanks @UDF11HLKC. Debugging the batching can be tricky. we implement both DataSource and BatchedSource indeed, maybe you can share some code?

Yeah my example only caches, no batching. You need to implement u/BatchedSource to do batching

Got it. Thanks.

(s/def-superfetcher FetchSession [id context]
  (fn [coll _]
    (map clj->gql
         (identity/find-session-by-ids context (map core/to-eids coll)))))

(def fetch-session-by-id ->FetchSession)

So whats important to know tho, the superlifter macro will use (:id this) as identity for your datasource. If you truly care about using the right database value for the right subquery, you need to incorporate the database value in your cache key.

I strongly recommend trying the record / protocol, and work your way back

Got it, thanks!