Hi @U5NCUG8NR. Cool that you are interested in this 👍 Afaik updating the connection is exactly the problem right now. We need to think of a way to make the reading datahike-instances aware of writes from other instances. This seems not so straightforward. Maybe @UB95JRKM3 @U1C36HC6N or @UQVCR784A can chime in here.

It's possible that dat.sync could be reworked towards this end. It's built around datomic & datascript, but honestly, the (relatively few) points of impedence mismatch between the two made the project very challenging. Focusing on datahike <-> datahike would be a lot easier methinks, and as far as I can tell all of the basic pieces are in place in datahike to make it happen.

I know that @U1C36HC6N has also thought a lot about distribution as part of datahike itself though, and it's definitely been designed with that in mind. I don't know if there's been any work towards that or where it might fall on the roadmap though.

@U5NCUG8NR This is already possible https://lambdaforge.io/2019/12/08/replicate-datahike-wherever-you-go.html, but yes the shared address space will make this happen automatically.

Thanks! This is exactly what I was looking for!

This seems like the perfect application for agents if the system uses a timeout-based re-connect rather than a file watch, which would be more ideal for e.g. a postgres kv-store backend

(def db (agent (d/connect :whatever)))

;; on init
(send-off db
          (fn refresh-db [_old-db]
            (Thread/sleep 5000)
            (d/connect :whatever)
            (send-off db refresh-db)))

;; in the code
(d/q '[:whatever] @db)

For my usecases this is perfectly fine as all I'm looking for is eventual consistency, and having a delay between a write and reads detecting that write is fine.

Yes, I think this is a fairly general setup that should work fine.