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.
