ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Entry filter in IgniteCache#loadCache
Date Tue, 21 Feb 2017 22:45:32 GMT
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