On 24 Sep 2014, at 09:10, Radim Vansa <rvansa(a)redhat.com> wrote:
On 09/24/2014 08:16 AM, Galder Zamarreño wrote:
> On 23 Sep 2014, at 19:02, William Burns <mudokonman(a)gmail.com> wrote:
>
>> On Tue, Sep 23, 2014 at 12:20 PM, Galder Zamarreño <galder(a)redhat.com>
wrote:
>>> On 23 Sep 2014, at 14:53, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>>
>>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>>>>
>>>>>> I am not sold on this as it seems pretty trivial to decipher
which
>>>>>> operation is which and the information would be present on the
>>>>>> javadocs as well.
>>>>> I very strongly disagree. Cf the other thread with Radim 's
comment on topology error.
>>>>> And think about *future* evolutions. The enum would make that much
safer. In the bin enum world you would have to introduce a new YetAnotherKeyValueFilter
interface :)
>>>> Nicer than an enum would be an explicit method, e.g.
handlePut/handleDelete/handleCreate/handleUpdate, as these would also receive the
appropriate param list.
>>> ^ Hmmmmm, not sure I like that. If you look at the remote event blog posts,
you’ll see that I use create/modify/remove annotations and then the parameter to the
callback varies depending on whether you had converter applied to it or not. IOW, without
a converter, a created event parameter is a ClientCacheEntryCreatedEvent, whereas with a
converter, the parameter is a ClientCacheEntryCustomEvent. Two different types of events
for the same event type. If you did it with explicit methods, you’d have to duplicate them
for custom events.
>> This is for embedded and is done in the filter and converter (not in
>> the listener). Unless I am missing something this shouldn't directly
>> affect the client methods.
> Ah ok.
>
>>>> Of course this means moving away from the KeyValueFilter to an
UpdateFilter (good name, Radim) used only for cluster listeners.
>>> I don’t like the name actually. I associate update with modifications, and in
similar vein, inserts with creation and delete with removals.
>> What would you suggest? A few things I thought of quickly:
>> CacheOperationFilter, CacheEventFilter, CacheWriteFilter - the only
>> reason I preface Cache is because we have CacheManager events as well.
> Maybe CacheEventFilter...
Does expiration trigger clustered listeners?
Expiration events are not there yet:
https://issues.jboss.org/browse/ISPN-694
It’s assigned to me but I’ve had my hands full with HR 2.0 related stuff...
'Event' sounds quite
generic, I would expect the EventFilter to be able to handle
expirations, invalidations, evictions etc., maybe even reads as well
(whether through separate methods or enums).
You can indeed listen for cache entry visited events, at least in local listeners.
ModificationFilter could be better (in TX I think we use term
'modifications' for all CUD ops), but we have already used
CacheEntryModified for 'update'.
>
>>>> Will, what would be the overall impact on the API as right now the
KeyValueFilter is reused between several components, like the cluster iterator.
>>>>
>>>> Cheers,
>>>> --
>>>> Mircea Markus
>>>> Infinispan lead (
www.infinispan.org)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Galder Zamarreño
>>> galder(a)redhat.com
>>>
twitter.com/galderz
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> galder(a)redhat.com
>
twitter.com/galderz
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz