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. 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;
}
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);
Vladimir.
On Tue, Sep 12, 2017 at 3:35 PM, Yakov Zhdanov <yzhda...@apache.org> wrote:
> Dmitry, can you please take a look at public API change.
>
> Ticket - https://issues.apache.org/jira/browse/IGNITE-425
> PR - https://github.com/apache/ignite/pull/2372
>
> Issues:
> 1. Do you see any other option other than creating separate class? As for
> me I don't.
> 2. In a new class we still have initial query which uses <K, V> types which
> is questionable.
>
> Igniters, please share your thoughts as well. Public API is the face of our
> product we need to make it as convenient and consistent as we can.
>
> --Yakov
>
