> So are you proposing something like process an event and decide that you will
> have to re-query, fails the promise with a “CacheInvalidatedException” and
> then in the recovery function perform the re-query and then just keep
> processing events on the stream?
Technically it would be a new P
On Thu, Nov 15, 2018 at 7:25 AM Tim Ward wrote:
> My expectation is that after the "flush error event", I can again accept
> new published event and process those until I get another case where the
> cached information is invalidated (i.e. the notification event changes the
> result set and ther
> My expectation is that after the "flush error event", I can again accept new
> published event and process those until I get another case where the cached
> information is invalidated (i.e. the notification event changes the result
> set and there is no way to simply update the cache and we h
Tim,
One thing that I'm unsure about your suggestion. My expectation is that
after the "flush error event", I can again accept new published event and
process those until I get another case where the cached information is
invalidated (i.e. the notification event changes the result set and there
is
The correct option will depend on what you want to happen. If you use an
endOfStream() or close() operation then you are telling your push stream that
the data has reached a “natural end”. This will cause the promise at the end of
your stream to resolve normally. This may be the right thing in s
We are using a push stream to process data change notifications against a
cached result set. Some of those notifications can result in directly
applying updates to the result set, while other will force us to invalidate
the cached result set.
When we do a requery, we want to make sure that any su