ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Entry filter in IgniteCache#loadCache
Date Wed, 22 Feb 2017 03:04:03 GMT
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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message