I meant "It is much better *than* extend*ing* confusing behavior *of *already confusing and overengineered API."
On Tue, Sep 12, 2017 at 7:35 PM, Vladimir Ozerov <voze...@gridgain.com> wrote: > Nikolay, > > Public API is the face of our product. We cannot and do not want to change > it in a rush. This ticket was in a backlog for more than 2 years. It is not > a big problem if we spend additional week or month for API design. It is > much better to extend confusing behavior on already confusing and > overengineered API. > > On Tue, Sep 12, 2017 at 6:47 PM, Николай Ижиков <nizhikov....@gmail.com> > wrote: > >> Vova >> >> > I propose to deprecate current continuous queries and develop new API. >> > This should not break anything. >> >> If the community agrees that *whole* continuous query API is bad - it OK. >> Let's develop new API. >> >> But developing new public API and implementing it is a very long process. >> One can see it based on this thread :) >> >> I think my implementation [1] of transformers for ContinuousQuery make >> things better for a user because remote transformers can lead to >> significant performance win. >> >> > Adding transformers on top of current API will make it total mess. >> >> I propose two things: >> >> 1. Continue discussion of current task [2] with scope limited by current >> API. >> 2. Start a discussion and work on new API. I think we can start with >> listing things that make current API bad. I can drive such a discussion. >> >> [1] https://github.com/apache/ignite/pull/2372 >> [2] https://issues.apache.org/jira/browse/IGNITE-425 >> >> >> 2017-09-12 17:55 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: >> >> > Vladimir, are their factories for the proposed listeners? >> > >> > On Tue, Sep 12, 2017 at 7:52 AM, Alexey Goncharuk < >> > alexey.goncha...@gmail.com> wrote: >> > >> > > Vladimir, >> > > >> > > Can you please clarify how the proposed API will work? >> > > >> > > My opinion is that our query API is big piece of ... you know, >> especially >> > > > ContinuousQuery. A lot of concepts and features are mixed in a >> single >> > > > entity, what makes it hard to understand and use. Let's finally >> > deprecate >> > > > ContinuousQuery and design nice and consistent API. E.g.: >> > > > >> > > > interface IgniteCache { >> > > > UUID addListener(CacheEntryListener listener) >> > > > void removeListener(UUID listenerId); >> > > > } >> > > > >> > > > This method set's a listener on all nodes which will process event >> > > locally, >> > > > no network communication. >> > > >> > > >> > > Do I understand correctly that CacheEntryListener will have a method >> like >> > > onEvent() which will accept the cache event? >> > > >> > > >> > > > Now if you want semantics similar to existing >> > > > continuous queries, you use special entry listener type: >> > > > >> > > > class ContinuousQueryCacheEntryListener implements >> CacheEntryListener >> > { >> > > > ContinuousQueryRemoteFilter rmtFilter; >> > > > ContinuousQueryRemoteTransformer rmtTransformer; >> > > > ContinuousQueryLocalCallback locCb; >> > > > } >> > > > >> > > > >> > > This becomes confusing: while the ContinuousQueryCacheEntryListener >> > itself >> > > has the onEvent() method, which is supposed to be called on event >> nodes, >> > it >> > > also has a rmtFilter, which will also be called on event nodes. Will >> the >> > > onEvent() then invoked on the listener anyway, regardless of the >> filter >> > > result? Finally, the listener will have a local callback field, which >> > will >> > > be called on the originating node. This sounds way more tricky to me >> than >> > > the current API. >> > > >> > > >> > > > Last, "initial query" concept should be dropped from "continuous >> query" >> > > > feature completely. It doesn't guarantee any kind of atomicity or >> > > > visibility wrt to cache events, so it adds no value. The same >> behavior >> > > > could be achieved as follows: >> > > > >> > > > cache.addListener(...) >> > > > QueryCursor cursor = cache.query(initialQuery); >> > > > >> > > > >> > > Agree with this. >> > > >> > >> >> >> >> -- >> Nikolay Izhikov >> nizhikov....@gmail.com >> > >
