On Friday, July 11, 2014 9:20:07 AM UTC-7, David Della Costa 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. > > > > 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. > >
Oh interesting! I completely missed that in the docs. I think some more examples of the various versions would be great. What comes out of tx-listen when you do this? I also notice that you can't add a tag to these according to the docs, which means using om-sync will be tough, correct? > > 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. > > I do have that right now, however, I can invert it and make it so that instead of saving directly onto the object, it gathers the edits and then does them all at once. However, from your other emails, it sounds like you would recommend keeping the components separate, have them save directly into the cursor, and then sort it all out inside :tx-listen instead of inverting control, having the main component gather the current state, and save all of the edits in a single pass? After typing it here, it does seem like keeping the server serialization complexity inside :tx-listen is probably better than sprinkling it throughout the various components. --Todd > > 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.
