Dima,
We definitely can have factories if we want.
On Tue, Sep 12, 2017 at 5:55 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
> 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.
> >
>
