We're having success with the Datomic <-> Datascript scenario by treating
the Datascript DB as an immutable value, rather than a ref + transactor, at
least in the case for user's interactively changing data. When the user
loads the data required for a scenario (e.g. editing an entity), we hold
For anyone else looking at this option, here is some code which is doing
the work on the cljs side.
https://gist.github.com/henryw-erudine/73cbcdea1eda150e78da
The server code is straightforward so not included.
--
You received this message because you are subscribed to the Google
Groups "Clo
hi Leon, thanks for your response. yes its true it wont suit all
situations.
in this case the user is changing their own data. and i think it will be
nice to allow for of undo/redo locally then single 'done with changes'
transaction back to datomic.
On Thursday, January 29, 2015 at 10:10:28
I have considered the approach once and dropped it quickly.
The key problem is the loss of atomicity. It introduces a second transactor
(the Datascript transactor) and thus synchronization requirements that can
rarely be fulfilled. One example where they would be fulfilled
automatically is whe
I am knocking out a webapp, backed by datomic on the server side and
planning to use datascript in the client.
the plan is to:
1) export a bunch of related data to the client (datomic query/pull/entity
apis to create edn data suitable for transact into datascript)
-- could be a one-time thin
