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.
