the Datomic/Datascript model uses [e a v t] representation for datoms. In other words: EntityId Attribute Value TransactionId.
This is very structured data, which means that we could potentially store this in sqlite.
Currently we do this through a little hack: we store the transaction content inside the value of the element that we want to store. For example: {:user/city [:city/name "Frankfurt"]}.
That gets the job done but also requires a lot of manual maintenance and care to do it correctly.
Here I propose an alternative. Store the datoms themselves inside a sql table and add/delete them on the fly based on datascript content.
Datascript exposes a connection listener which will return the old DB value, the new DB value and the transaction itself. Since both DB are just datoms, it should be possible to just diff them and add/delete datoms based on it.
This process can be quite automatic and simple to maintain. The developer would simply have to annotate the transaction with metadata regarding wether or not to persist the data.
For example (db/transact! [{:user/city [:city/name "Frankfurt"]}] :store/persistent)
This would inform the conn listener that the resulting data should be stored
The main benefit of this approach is that the complete state can be restored on app start !! 🚀
the Datomic/Datascript model uses
[e a v t]
representation for datoms. In other words:EntityId Attribute Value TransactionId
.This is very structured data, which means that we could potentially store this in sqlite.
Currently we do this through a little hack: we store the transaction content inside the value of the element that we want to store. For example:
{:user/city [:city/name "Frankfurt"]}
.That gets the job done but also requires a lot of manual maintenance and care to do it correctly.
Here I propose an alternative. Store the datoms themselves inside a sql table and add/delete them on the fly based on datascript content.
Datascript exposes a connection listener which will return the old DB value, the new DB value and the transaction itself. Since both DB are just datoms, it should be possible to just diff them and add/delete datoms based on it.
This process can be quite automatic and simple to maintain. The developer would simply have to annotate the transaction with metadata regarding wether or not to persist the data.
For example
(db/transact! [{:user/city [:city/name "Frankfurt"]}] :store/persistent)
This would inform the conn listener that the resulting data should be stored
The main benefit of this approach is that the complete state can be restored on app start !! 🚀