Transaction Log with Tuple Database Support?

I could be be way off base going down this particular path of exploration and better off sticking to Key/Value or Graph abstractions so I welcome any community feedback. I have more time to find new ideas than program right now so it’s easy to get far afield! So apologies for this set of not fully-formed ideas, but I trust people will engage only if they are interested. I have only built things on Redux too so I am trying to see how my thinking needs to map to RSM. If there happen to be a few good ideas embedded in here and they get broken out and realized in a different way that is fine as well.

I have a problem space I am looking at as more of a general utility. Extending and modifying the data schema would be the norm rather than the exception. I imagine lots of hApps and their associated DNA’s with a fixed schema and functions that tightly control things so this would be the opposite of that. I have become enamored of Clojure’s approach to data and then also one of it’s logical extensions which is the Datomic database. It’s unit of storage is a datom which is essentially a combination of an entity, attribute, value, a transaction, and a true/false to indicate whether the fact is being stated or retracted. They use datalog as an in-application query engine for the database. I like the datalog approach because I just say what information I want and assert whatever Entity/Attribute/Value tuples I can, and it figures out what the answer is. It seems to me to be less work that what I have to declare to get SQL or Graph QL type of queries to work. I’m imagining a general purpose UI that needs to pull some data from one or more of these general data sets, possible some hApps or other services, and the UI itself. It stores everything in an in-memory datomic style of database that gets queried via datalog. I think this is preferable to implementing the database engine in Holochain since the whole point is to be able to flexibly combine different data, but that could be another useful endpoint.

The transactional aspect of things seems really useful to me. When I’m updating software, version control collects together a bunch of changes all made for a particular reason. I like the idea that myself and users of business applications I create are encouraged to take on making a series of changes for a purpose. They have a problem statement, do some research, make some analysis, and then make some changes. They should be able visualize the impact of the changes and apply them when it looks good. They should also be able to back out whole sets of changes and ask questions about a time as-of a particular change. It gives a whole narrative feel which I think really resonates with people.

Mapping this to Holochain I imagine could be done on a bit of a spectrum from least backend work to most.

Minimal Backend: In the simplest case, all you emulate is a transaction log. The data is assumed to be tractable enough that the clients can just wade through the chain and load the transactions they are interested in. This doesn’t seem totally far-fetched as I remember in my dev camp with the game that many patterns will amount to running through a significant majority of transactions to come up with a derived current state. It seems like with the caching being done that much of this could be pretty fast.

Transaction Log Plus Pulling Entities: In this scenario, you would have the transaction entries, and then also create an entry for each unique “Entity”. Presumably some anchors would have to be created also to help find a useful set of entities for an application to work with. They would then find all the entities, load all the linked transactions, and then load more entities that might be referred to in the “value” fields as needed.

Full Datom storage plus indexes: Now imagine a scenario which the process transaction function explodes it into a series of datoms that get created as entities. Indexes would then get simulated with a series of updates to the anchors. You could also force attributes to be defined with a data type and cardinality and then enforce that when the transaction is applied.

I get really fuzzy on how exactly to use the anchors. I do see also that links have a simple way of querying them against a prefix. If that is efficient, it would be another way to go after creating these indexes.