Entry filter in IgniteCache#loadCache

[Valentin Kulichenko]

Igniters,

Currently IgniteCache.loadCache has optional entry filter that can be
passed as an argument. It seems to be redundant because:

   - Filtering that is done by this filter can be as well implemented
   within CacheStore itself. Moreover, if the filtering can be done on DB
   level, it's better from performance standpoint.
   - In case filtering has to be dynamic (i.e. use does wants to provide a
   predicate as an argument), generic arguments can be used.

Having said that, this predicate doesn't add any value and therefore
creates confusion. And frankly, I've never seen anyone using it. I suggest
to remove it completely in 2.0.

Thoughts?

-Val

[Vladimir Ozerov]

+1

On Sat, Feb 18, 2017 at 11:51 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igniters,
>
> Currently IgniteCache.loadCache has optional entry filter that can be
> passed as an argument. It seems to be redundant because:
>
>    - Filtering that is done by this filter can be as well implemented
>    within CacheStore itself. Moreover, if the filtering can be done on DB
>    level, it's better from performance standpoint.
>    - In case filtering has to be dynamic (i.e. use does wants to provide a
>    predicate as an argument), generic arguments can be used.
>
> Having said that, this predicate doesn't add any value and therefore
> creates confusion. And frankly, I've never seen anyone using it. I suggest
> to remove it completely in 2.0.
>
> Thoughts?
>
> -Val
>

[dsetrakyan]

On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
[hidden email]> wrote:

> Igniters,
>
> Currently IgniteCache.loadCache has optional entry filter that can be
> passed as an argument. It seems to be redundant because:
>
>    - Filtering that is done by this filter can be as well implemented
>    within CacheStore itself. Moreover, if the filtering can be done on DB
>    level, it's better from performance standpoint.
>

What if user configures our standard JDBC store? How will the customer
filtering logic be added in this case?


>    - In case filtering has to be dynamic (i.e. use does wants to provide a
>    predicate as an argument), generic arguments can be used.
>

Not sure what you mean by "generic arguments". Can you explain?


>
> Having said that, this predicate doesn't add any value and therefore
> creates confusion. And frankly, I've never seen anyone using it. I suggest
> to remove it completely in 2.0.
>

I am not sure if I agree. Why break API compatibility here for no apparent
benefit?


>
> Thoughts?
>
> -Val
>

[Valentin Kulichenko]

On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> [hidden email]> wrote:
>
> > Igniters,
> >
> > Currently IgniteCache.loadCache has optional entry filter that can be
> > passed as an argument. It seems to be redundant because:
> >
> >    - Filtering that is done by this filter can be as well implemented
> >    within CacheStore itself. Moreover, if the filtering can be done on DB
> >    level, it's better from performance standpoint.
> >
>
> What if user configures our standard JDBC store? How will the customer
> filtering logic be added in this case?
>

Our store accepts custom SQL queries. This should be enough to do any
filtering and it's also better from performance standpoint.


>
>
> >    - In case filtering has to be dynamic (i.e. use does wants to provide
> a
> >    predicate as an argument), generic arguments can be used.
> >
>
> Not sure what you mean by "generic arguments". Can you explain?
>

I mean array of arguments passed to CacheStore.loadCache() method. Any
arguments can be used there, including predicates.

>
>
> >
> > Having said that, this predicate doesn't add any value and therefore
> > creates confusion. And frankly, I've never seen anyone using it. I
> suggest
> > to remove it completely in 2.0.
> >
>
> I am not sure if I agree. Why break API compatibility here for no apparent
> benefit?
>
>
> >
> > Thoughts?
> >
> > -Val
> >
>

[dsetrakyan]

Val, do you think this change will be worth breaking backward API
compatibility?

On Tue, Feb 21, 2017 at 2:45 PM, Valentin Kulichenko <
[hidden email]> wrote:

> On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan <[hidden email]
> >
> wrote:
>
> > On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> > [hidden email]> wrote:
> >
> > > Igniters,
> > >
> > > Currently IgniteCache.loadCache has optional entry filter that can be
> > > passed as an argument. It seems to be redundant because:
> > >
> > >    - Filtering that is done by this filter can be as well implemented
> > >    within CacheStore itself. Moreover, if the filtering can be done on
> DB
> > >    level, it's better from performance standpoint.
> > >
> >
> > What if user configures our standard JDBC store? How will the customer
> > filtering logic be added in this case?
> >
>
> Our store accepts custom SQL queries. This should be enough to do any
> filtering and it's also better from performance standpoint.
>
>
> >
> >
> > >    - In case filtering has to be dynamic (i.e. use does wants to
> provide
> > a
> > >    predicate as an argument), generic arguments can be used.
> > >
> >
> > Not sure what you mean by "generic arguments". Can you explain?
> >
>
> I mean array of arguments passed to CacheStore.loadCache() method. Any
> arguments can be used there, including predicates.
>
>
> >
> >
> > >
> > > Having said that, this predicate doesn't add any value and therefore
> > > creates confusion. And frankly, I've never seen anyone using it. I
> > suggest
> > > to remove it completely in 2.0.
> > >
> >
> > I am not sure if I agree. Why break API compatibility here for no
> apparent
> > benefit?
> >
> >
> > >
> > > Thoughts?
> > >
> > > -Val
> > >
> >
>