ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: ContinuousQueryWithTransformer implementation questions - 2
Date Tue, 12 Sep 2017 16:32:59 GMT
Dima,

We definitely can have factories if we want.

On Tue, Sep 12, 2017 at 5:55 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> Vladimir, are their factories for the proposed listeners?
>
> On Tue, Sep 12, 2017 at 7:52 AM, Alexey Goncharuk <
> alexey.goncharuk@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message