On 09/24/2014 08:16 AM, Galder Zamarreño wrote: > On 23 Sep 2014, at 19:02, William Burns <mudokon...@gmail.com> wrote: > >> On Tue, Sep 23, 2014 at 12:20 PM, Galder Zamarreño <gal...@redhat.com> wrote: >>> On 23 Sep 2014, at 14:53, Mircea Markus <mmar...@redhat.com> wrote: >>> >>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard <emman...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> -- >>> Galder Zamarreño >>> gal...@redhat.com >>> twitter.com/galderz >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > gal...@redhat.com > twitter.com/galderz > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
