Clojurians Log v2
asami
I feel like the ideal world would be a software combination allowing an Asami-like graph database that runs both locally and the server, and that allows automatic sync between them as well as between other users. It seems like maybe this would be possible with a combination of Asami and Electric by Hyperfiddle and maybe the ideas behind Automerge. I saw this article from the Automerge creator Martin Kleppman talking about the possibility of CRDTs as Datalog - and made me think if those principles somehow overlapped enough with Asami one day that future is possible: https://martin.kleppmann.com/2018/02/26/dagstuhl-data-consistency.html
FYI there's an edn Datalog implementation of Martin's RGA example (from that 2018 talk) here: https://github.com/sixthnormal/clj-3df/blob/7dfb89a438f9fb1a3c5d0d356f05acf3f9c51177/examples/rga.clj ...which runs on the same engine that https://materialize.com/ uses: https://github.com/TimelyDataflow/differential-dataflow I've never studied it deeply, but my impression of this particular CRDT+Datalog approach is that you really do need incremental view maintenance (i.e. extensional inferencing, instead of query-time inferencing) if you want it to work at any sort of serious scale
Asami with Electric would be really awesome because having the exact same database structure in the front and back end paired with Electric's sync could simplify a lot of things. (I wonder if pairing with something like Automerge could somehow also help with conflict resolution for more than one user?) This is definitely a niche Asami fills better than XTDB or Datomic since those can't run on the client at all. And thinking about some of the long-term possibilities of Electric paired with Asami open some interesting possibilities as well - while electric currently is designed to manage network sync between your front and back end, it sounds like it could eventually be directed at n-peers, meaning one day it could offer peer to peer sync of front-end only / local first Asami databases? It also sounds like they're working on some kind of "differential" Electric to only sync changes as well.
> would be possible with a combination of Asami and Electric by Hyperfiddle
This electric demo uses datascript.
https://electric.hyperfiddle.net/(electric-tutorial.demo-webview!%57ebview)/
An easy starting point would be to add a way to e/watch the asami database?
Seems fair. It could go at the end of the transaction operation?
Indeed. It should be easy enough to test that without changes to asami actually.
Just wrap d/transact in a defn my-transact that bounces an atom and e/watch said atom.
I’ll have to read this when I get time. I’ve been giving thought to this over the years. I don’t know about merging graphs, but the architecture allows for lots of modifications to all take place concurrently, then use block replication to ensure that everyone gets all of these updates. But that’s like everyone creating their own Git branches, and never merging. From a naïve perspective, graphs are actually easy to merge, since everything is either deleted or inserted, and nothing is ever changed in place. However, that ignores that groups of triples are describing an entity, and they work together to do this. What level of semantics need to be considered when merging, and how generalizable is the approach?
I’m happy to look at any resources around this. I’ve had various discussions around it for years, but never come to a satisfactory position on it.
What about something like a sparql union graph that is synchronized transactionally across all of the named graphs in an asami dataset? Cf https://patterns.dataincubator.org/book/union-graph.html