> I think in my head it was a version of transact! that took a vector > of korks and functions and mutated the state in a single pass.
Maybe I'm still misunderstanding but you can certainly alter multiple values in a single pass both with local component state as well as cursor data: (transact! cursor #(assoc % :foo "foo" :bar "bar")) ; etc. https://github.com/swannodette/om/wiki/Documentation#transact https://github.com/swannodette/om/wiki/Documentation#update-state I was under the impression, however, that you had a bunch of different components each separately transact!-ing on app data at different, asynchronous points in time. Let me know if I'm off-base on one or the other here. DD (2014/07/11 23:42), Todd Berman wrote: > I think in my head it was a version of transact! that took a vector > of korks and functions and mutated the state in a single pass. > > An obvious problem with that would be the need to change/extend the > tx-listen callback, which I am not clear of the feasibility of. > > My plan w/o something like that is to implement a similar setup to > what you are talking about where tx-listen changes are posted to a > queue that is processed after N ms of inactivity to make sure to > generate as few changes as possible to the server. > > Perhaps instead of a transact! change, the right way to approach it > is to provide tx-listen helpers that buffer and dedup changes to > make implementing something like this (which seems like it would be > a common need) easily? > > --Todd > > On Friday, July 11, 2014 2:30:07 AM UTC-7, Daniel Kersten wrote: >> I guess it would need some kind of commit call? >> >> >> What I'm doing is placing the :tx-listen messages onto a >> core.async channel that then accumulates multiple changes before >> sending them to the server. I haven't quite finalised the strategy >> yet, but this way gives me options and I'm playing around with a >> mechanism that will send data to the server either every N >> transactions or after X milliseconds of receiving no new >> transactions, whichever happens sooner. >> >> >> >> >> This way the server-batch-sending happens outside of Om and my Om >> code doesn't need to know or care about it. >> >> >> >> On 11 July 2014 06:53, Dave Della Costa <[email protected]> >> wrote: >> >> >> How would a "multiple operation transaction" version of transact! >> work? >> >> >> >> >> >> (2014/07/11 0:20), Todd Berman wrote: >> >>> On Thursday, July 10, 2014 12:23:53 AM UTC-7, David Della Costa >> >>> wrote: >> >>>> Hi Todd, >> >>>> >> >>>> >> >>>> >> >>>>> So, for example, if you edit all 3 fields, it causes 3 saves >>>>> to >> >>>>> be >> >>>> >> >>>>> sent, which isn't what I want at all. >> >>>> >> >>>> >> >>>> >> >>>> Can you go into a bit more detail about why this is the case? >> >>>> >> >>>> >> >>>> >> >>>> I can say that whatever the case may be, I would be hesitant >>>> to >> >>>> >> >>>> incorporate any logic for how the server should receive >>>> updates >> >>>> anywhere >> >>>> >> >>>> but in the tx-listen function. >> >>> >> >>> Unclear which case you are asking about. >> >>> >> >>> I don't want 3 saves to happen when 1 save can happen with all >>> of the >> >>> information, especially because put 1, 2 and 3 are all using >>> various >> >>> snapshots of the data (where 1 has edit 1, 2 has edit 1 and 2 >>> and 3 >> >>> has edit 1, 2 and 3), with put 3 being the 'correct' one. >>> However, >> >>> due to how the backend in question works, the writes are queued, >> >>> idempotent and not strictly ordered, so there are cases where >>> put 2 >> >>> is the last one executed, which results in improper data being >>> saved >> >>> on the backend. >> >>> >> >>> The reason that is happening right now is there are 3 >>> om/transact >> >>> calls, thus 3 calls to tx-listen, and it is unclear to me how I >>> can >> >>> guarantee that I don't do that w/o cooperation from the >>> components, >> >>> since there is no 'multiple operation transaction' support in >> >>> om/transact >> >>> >> >>> If that wasn't the question you were asking, let me know! >> >>> >> >>> --Todd >> >>> >> >> >> >> -- >> >> Note that posts from new members are moderated - please be patient >> with your first post. >> >> --- >> >> You received this message because you are subscribed to the Google >> Groups "ClojureScript" group. >> >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [email protected]. >> >> To post to this group, send email to [email protected]. >> >> Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
