You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Valentin Kulichenko <va...@gmail.com> on 2017/02/18 20:51:32 UTC
Entry filter in IgniteCache#loadCache
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
Re: Entry filter in IgniteCache#loadCache
Posted by Dmitriy Setrakyan <ds...@apache.org>.
Val, do you think this change will be worth breaking backward API
compatibility?
On Tue, Feb 21, 2017 at 2:45 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> >
> wrote:
>
> > On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> 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
> > >
> >
>
Re: Entry filter in IgniteCache#loadCache
Posted by Valentin Kulichenko <va...@gmail.com>.
On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:
> On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> 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
> >
>
Re: Entry filter in IgniteCache#loadCache
Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> 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
>
Re: Entry filter in IgniteCache#loadCache
Posted by Vladimir Ozerov <vo...@gridgain.com>.
+1
On Sat, Feb 18, 2017 at 11:51 PM, Valentin Kulichenko <
valentin.kulichenko@gmail.com> 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
>