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... > >> >>> 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
