On Thu, Mar 13, 2014 at 5:58 PM, William Burns <mudokonman@gmail.com> wrote:

On Thu, Mar 13, 2014 at 11:54 AM, Vladimir Blagojevic

<vblagoje@redhat.com> wrote:
> On 3/13/2014, 11:39 AM, William Burns wrote:
>> On Thu, Mar 13, 2014 at 11:14 AM, Vladimir Blagojevic
>> <vblagoje@redhat.com> wrote:
>>> Mircea and I wanted to "promote" AdvancedCacheLoader.KeyFilter or merge
>>> it with one filter we all choose to use because we have so many of these
>>> internal filter classes it is ridiculous. The filter you wrote is THE one?
>> I can't say that for sure. Basically the KeyFilter that exists in the
>> notifications package was what I was going to use as it is more
>> generic since the method is called accept, which I thought was better
>> than shouldLoadKey.
>>
>> Are we thinking we would get rid of the KeyFilter and only use
>> KeyValueFilter though ?
>>
>> - Will
>>
> Not sure Will. I would move both KeyFilter and KeyValueFilter in some
> major package so we can all use it throughout the codebase!

That is exactly what I was hoping to do with the new
org.infinispan.filter package in core module.

I would definitely keep KeyFilter, I imagine there are places where we don't have the value yet and we'd have to load it from a store to pass it to the filter.

Even for clustered listeners, it might make a difference for the initial transfer - although deciding which is optimal, loading all the keys and then loading accepted values one by one, or loading all the values upfront, isn't really doable without a hint from the user.

In a way I also see an overlap between KeyValueFilter and Converter. At least with SingleFileStore, KeyFilter can be used to filter keys before doing any real work, whereas KeyValueFilter/Converter can only be used to trim the amount of information to send over the network after the entry has been fully loaded.

Dan