It's possible in SQL, in Datascript it's effortless. There's a big difference in mental overhead and thus how often you would want reach into DB. There are other benefits.
You don't do any string mungling, your query is itself composed of data structures. You can build it easily with code, so your queries become as elaborate as you can generate them.
Unlike SQL tables that you have to figure out from start, the data model is a collection of facts, with each fact consisting of {entity_id, attribute, value, transaction_info}. By adding facts to database you build the knowledge about entities and different relations between entities in an organic way. You can still use the table model, or you can use graph model.
The whole DB is just a value in memory. You can transit it to server, store history copies in memory (for undo/redo), do diffs, whatever you need.
As for monitoring changes, I'm using the Posh lib (also mentioned in article). It monitors the DB and re-renders react component if there are transactions relevant to component's queries. It seems very efficient so far, but I still have to test it with large number of components and transactions.
> As for monitoring changes, I'm using the Posh lib (also mentioned in article). It monitors the DB and re-renders react component if there are transactions relevant to component's queries. It seems very efficient so far, but I still have to test it with large number of components and transactions.
Interesting. Do you know if, upon a change, it reruns the queries from scratch, or does it update the results based on the actual changes?
It will re-run the queries whenever new transactions contain new data for queried entities. It does so by pattern matching on transaction data.
For truly reactive datalog subscriptions, let's see what happens with clj-3df project. Unlike Datascript, it requires you to use server infrastructure right from start.
You don't do any string mungling, your query is itself composed of data structures. You can build it easily with code, so your queries become as elaborate as you can generate them.
Unlike SQL tables that you have to figure out from start, the data model is a collection of facts, with each fact consisting of {entity_id, attribute, value, transaction_info}. By adding facts to database you build the knowledge about entities and different relations between entities in an organic way. You can still use the table model, or you can use graph model.
The whole DB is just a value in memory. You can transit it to server, store history copies in memory (for undo/redo), do diffs, whatever you need.
As for monitoring changes, I'm using the Posh lib (also mentioned in article). It monitors the DB and re-renders react component if there are transactions relevant to component's queries. It seems very efficient so far, but I still have to test it with large number of components and transactions.