I would postpone review until we come to a clear decision on what should be done if filter or transformer fails. I don't think cancelling query is too much. From my standpoint this is a kind of heuristic exception and may break some sensitive logic.
Thanks! -- Yakov Zhdanov, Director R&D *GridGain Systems* www.gridgain.com 2017-08-30 16:24 GMT+03:00 Nikolay Izhikov <[email protected]>: > Hello, Yakov. > > The new class is OK - got it. Thanks! > > > Should we extract a super class? > > Yes, we should. > I already have done it. > > See my last commit in PR - https://github.com/apache/igni > te/pull/2372/commits/af1ed2e4dbef4ba5999f8566198cb75ad922f93b > > > We can put hard requirement that filter and transformer cannot throw > > exception (same as cache interceptor). > > I think to cancel the whole query on transformer exception is too much. > After discussion, I like the idea to skip event if transformer throws > exception. As far as it "like regular filter" behavior. > > Thoughts? > > > 30.08.2017 16:03, Yakov Zhdanov пишет: > > I think I have already agreed on a separate class since it seems to be the >> only option due to generics issue. Should we extract a super class? >> >> We can put hard requirement that filter and transformer cannot throw >> exception (same as cache interceptor). If exception is thrown then we >> cancel the query globally and unregister all the listeners. This may sound >> too much but inconsistencies brought by listener notifications may be >> terrible for app. >> >> --Yakov >> >>
