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 PM UTC, Leon Grapenthin wrote: > > 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. > > > On Thursday, January 29, 2015 at 3:24:57 PM UTC+1, henry w wrote: >> >> 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 >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
