[infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6

[Dan Berindei]

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

> On Thu, Mar 13, 2014 at 11:54 AM, Vladimir Blagojevic
> <vblagoje at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140313/b988902a/attachment.html