Alex,
The source of our confusion in current API is that we called "filter" what
actually should be "listener". I propose to set has the simplest API
possible. Note that CacheEntryListener is a part of jcache API. Call of
this method will set passed listener on remote nodes. Nothing more.
UUID listen(CacheEntryListener listener)
Next, I propose to treat our current continuous queries implementation as a
specific implementation of CacheEntryListener interface. This
implementation will filter/transform events remotely, and then transfer
them to some "local" callback. This is it.
On Tue, Sep 12, 2017 at 5:52 PM, 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.
>
