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.kuliche...@gmail.com> wrote: > 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 > > > > > >
