Re: [infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6
On Thu, Mar 13, 2014 at 5:58 PM, William Burns <mudokonman(a)gmail.com> wrote:
On Thu, Mar 13, 2014 at 11:54 AM, Vladimir Blagojevic
<vblagoje(a)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(a)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
Attachments:
- attachment.html (text/html — 2.6 KB)