9:10 a.m.
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? '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).
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