datomic <-> datascript transfers

[henry w]

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 thing or seed data with more getting pulled later.
2) let the user change it about (transactions into datascript)
3) save all user changes back to datomic (could send complete list of transactions made on client back to server, but ideally one tx representing sum of all changes)

One issue to deal with is identity. For example upserts and retractions (on both client and server) need to happen to the right entities.

I have some plans for how it will all work, but before going into details I am just curious if anyone else has considered this general approach?

Thanks,
Henry

[Leon Grapenthin]

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 where the browser is the only instance with write access to the selected information. But in reality, this is almost never the case. Then, if you don't fulfill the synchronization requirements, your local DataScript database is an unreliable information source.

Instead, you can change step 2 with "Transactions into Datomic" (via HTTP request to your app) and stream the relevant Datoms from d/tx-listen via SSD back into the Datascript DB. So you only do transactions into the Datascript DB indirectly. 

Best regards,

 Leon.

[henry w]

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.

[henry w]

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.

[Dave Dixon]

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 the value as obtained from datomic and the updated value used by applying user changes through the with or with-db functions. When the user chooses to commit, we essentially diff the sets of datoms between the original and changed Datascript values (twice - once to get adds and once for retracts), as well as identify the Datascript id's of added entities. On the server, the new Datascript id's are converted into Datomic temp id's, and we just transact the transformed diff.

There are some differences in behavior which need to be worked around, particularly the behavior of :db/ident. We strictly use :db/ident only for attribute names and enums. This allows us to do the appropriate transformations to the data and pull patterns so that the differences between Datascript and Datomic are more or less hidden.

Works very well for editing hierarchical entities. The parent can simply pass it's Datascript value and the appropriate child id to the child editor. If the user commits the child changes, the parent simply takes the updated value of the db; if the user cancels, the parent doesn't need to do anything, as it is already holding the unchanged value.