Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAG7t879fUFJ7DgaE6NPPeVzgcKu3zfXi=YPHSLDvy21_xKTBiQ@mail.gmail.com>
References: <5a26383b-7d2e-9b02-6f56-7d207f565f23@gmail.com>
 <CAGcMBHianvu=gthrPikb+SNttg7vUqbkcqMPPcsf--b+2vSAFg@mail.gmail.com>
 <663b5cbd-2983-4501-e01b-e4803b77ccf1@gmail.com> <CAGcMBHjyMvnNaNQN8Qv1qZhr=FYOu0pkYv0XE0fRpUjMXR7QOA@mail.gmail.com>
 <3f745905-597a-d944-0239-b177e524aa16@gmail.com> <CAGcMBHiS6fMsruY7Qo=E=VOpZP21Kp2KjNFLMfe34L2Qdraxmw@mail.gmail.com>
 <bf91ab16-7ecd-9a85-827d-195ab7673afe@gmail.com> <CAFx+i-ZNBbNuPDUuAkJm6fEA66xvw9kFobWe7ENHrY0MxcgQVg@mail.gmail.com>
 <ac7a1639-fada-9a3f-a52a-5244b6b88734@gmail.com> <CAGcMBHgRuJv8UKpe2tugKSM1VqLCvo8FyN+QwePYM7Pn3WcnOw@mail.gmail.com>
 <6bc1acdd-d761-2a23-f1e2-b7b21e261ad8@gmail.com> <CAGcMBHgkz6iCCPQZVrw+6s46HUkYeUkQH38Sn5B6aq18ysbz_A@mail.gmail.com>
 <CAG7t878JeY98tkPEeCXQ+dJyHPaa+K8Q4-v_WdVrKoKK+hidQw@mail.gmail.com>
 <CAOKDqC-a3BARhpqzvo+O9r0MjA646MNcx5N7en=KmieOkfsMtQ@mail.gmail.com>
 <CAGcMBHgzDn0xkmVuQwrzAGsDkb42U-bJPt7_5+RZB57oTDECRg@mail.gmail.com>
 <CAG7t87_gFc6m4HRb=a=nqM40nDu2hTe7p5c9DTcR=PsYEyqTow@mail.gmail.com>
 <CAP3QaUE9mVtm0b2-BYo9uYV7XqS9i86CZoq4J8nLJ1Q5EZ9mEg@mail.gmail.com>
 <CAG7t87-Je7esXZe9M=c4DcrpjsugvgzHbXLQ7Bv3hYyF5FrJ+Q@mail.gmail.com>
 <CAGcMBHidDd5NG6VSWWWJDz=nBeH-JvZt1f_V0R67OzKMLxZoDg@mail.gmail.com>
 <CAGt6o8=URp2xLsM+nR3xPcb1d_JoEGhvRNeUn86N5vFYXHkewQ@mail.gmail.com>
 <CABDss3gkAd7W5YvvEbqMF_G7pnzZsxOCj+7VF69_usTJRLDOsQ@mail.gmail.com>
 <CA+0=VoWWRrNcJ_O407xJWAhL_Ms34V2McH_oACn=7+9x_yZwKg@mail.gmail.com> <CAG7t879fUFJ7DgaE6NPPeVzgcKu3zfXi=YPHSLDvy21_xKTBiQ@mail.gmail.com>
From: Vladimir Ozerov <vozerov@gridgain.com>
Date: Tue, 12 Sep 2017 19:35:05 +0300
Message-ID: <CAGt6o8=jQbf-SZC3GJQ82Zket25R4QO8x7nMzQf_S0OpXJgKSg@mail.gmail.com>
Subject: Re: ContinuousQueryWithTransformer implementation questions - 2
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a113f5b903831f3055900a09a"
archived-at: Tue, 12 Sep 2017 16:35:13 -0000

--001a113f5b903831f3055900a09a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Nikolay,

Public API is the face of our product. We cannot and do not want to change
it in a rush. This ticket was in a backlog for more than 2 years. It is not
a big problem if we spend additional week or month for API design. It is
much better to extend confusing behavior on already confusing and
overengineered API.

On Tue, Sep 12, 2017 at 6:47 PM, =D0=9D=D0=B8=D0=BA=D0=BE=D0=BB=D0=B0=D0=B9=
 =D0=98=D0=B6=D0=B8=D0=BA=D0=BE=D0=B2 <nizhikov.dev@gmail.com>
wrote:

> Vova
>
> > I propose to deprecate current continuous queries and develop new API.
> > This should not break anything.
>
> If the community agrees that *whole* continuous query API is bad - it OK.
> Let's develop new API.
>
> But developing new public API and implementing it is a very long process.
> One can see it based on this thread :)
>
> I think my implementation [1] of transformers for ContinuousQuery make
> things better for a user because remote transformers can lead to
> significant performance win.
>
> > Adding transformers on top of current API will make it total mess.
>
> I propose two things:
>
> 1. Continue discussion of current task [2] with scope limited by current
> API.
> 2. Start a discussion and work on new API. I think we can start with
> listing things that make current API bad. I can drive such a discussion.
>
> [1] https://github.com/apache/ignite/pull/2372
> [2] https://issues.apache.org/jira/browse/IGNITE-425
>
>
> 2017-09-12 17:55 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > 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 sing=
le
> > > > 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 filt=
er
> > > 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 =3D cache.query(initialQuery);
> > > >
> > > >
> > > Agree with this.
> > >
> >
>
>
>
> --
> Nikolay Izhikov
> NIzhikov.dev@gmail.com
>

--001a113f5b903831f3055900a09a--