On Mon, Feb 20, 2017 at 12:23 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote:
> On Sat, Feb 18, 2017 at 12:51 PM, Valentin Kulichenko < > valentin.kuliche...@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 > > >
