What I mean by "blind writes" is that the runner would have to have a backing service that supports the operation. Using a hidden ValueState would be a way to automatically support the APIs, but I think they could be implemented at lower cost without a state read. I'm willing to be wrong about the perf concerns; easier if I am.
Kenn On Fri, Nov 2, 2018 at 9:12 PM Reuven Lax <re...@google.com> wrote: > Those apis might make sense, but I'm not sure how they would be"blind > writes." I assume we would implement them by adding a hidden ValueState. > > On Fri, Nov 2, 2018, 11:01 PM Kenneth Knowles <k...@apache.org wrote: > >> There is not a way to check if a timer has been set. It would be a >> different & more expensive protocol if that API were available. Timers are >> deliberately a "blind write" API. The best approach today is just what you >> said - add a ValueState<Boolean>. But that negates the performance benefits >> of the API design. >> >> But your use case is actually probably many uses of timers. I'm adding >> the dev list to broadcast the use case. It probably makes sense to have a >> "set if unset" API and/or a "set to the minimum of current time and this >> new time" API, both still "blind writes". >> >> Kenn >> >> >> >> On Fri, Nov 2, 2018 at 8:55 PM Reza Ardeshir Rokni <raro...@gmail.com> >> wrote: >> >>> Hi, >>> >>> I have a need to set an alarm in both the Element DoFn as well as the >>> OnTimer code block. I need to ensure that I do not overwrite a already set >>> timer, is there a way to check if a Timer has been set? >>> >>> One thought was to use a ValueState<Boolean> which I can manually set / >>> unset as part of the operations. Thoughts? >>> >>> Cheers >>> Reza >>> >>
