On Tue, Sep 23, 2014 at 8:18 AM, Emmanuel Bernard <emman...@hibernate.org> wrote: > > > >> On 22 sept. 2014, at 19:23, William Burns <mudokon...@gmail.com> wrote: >> >> On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard >> <emman...@hibernate.org> wrote: >>> >>>> On 19 Sep 2014, at 17:09, William Burns <mudokon...@gmail.com> wrote: >>>> >>>> Comments regarding embedded usage are inline. I am not quite sure on >>>> the hot rod client ones. >>>> >>>> On Thu, Sep 18, 2014 at 12:24 PM, Emmanuel Bernard >>>> <emman...@hibernate.org> wrote: >>>>> >>>>> >>>>> That requires us to be able to provide the old and new value to the >>>>> KeyValueFilter and the Converter interface as well as the type of event >>>>> (creation, update, deletion). >>>> >>>> I agree the oldValue is required for most efficient usage. From the >>>> oldValue though it seems you can infer what operation it is. Create >>>> has null oldValue and delete has null newValue I would think. >>> >>> well except when I do cache.put(key, null) but that might not matter. >> >> We don't allow a null value to be passed to put. >> >>> The other use case is the includeInitialState where the old value would be >>> either null or the same as the new one? Could a user detect that state >>> based on old == new? >> >> It would have prevValue as null in this case. >> >>> At any rate the programming model becomes quite awkward and rely on strong >>> understanding, I’d prefer to stick an enum showing the transition >>> explicitly to make things easier. >> >> 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 :) > >>>>> >>>>> ## includeCurrentState and very narrow filtering >>>>> >>>>> The existing approach is fine (send a create event notif for all existing >>>>> keys and queue changes in the mean time) as long as the listener plans to >>>>> consume most of these events. >>>>> But in case of a big data grid, with a lot of passivated entries, the >>>>> cost would become non negligible. >>>> >>>> The filter and converter are applied while doing the current state so >>>> it should be performant in that case. >>> >>> I don’t understand, the code still has to look all key/value pairs of a >>> given node (at least the primary ones) and send them through the KVF / >>> Converter logic. So you need to unmarshal all of them as well as load from >>> cachestore the passivated ones. Correct? That’s the cost I am describing >>> here. >> >> Sorry I didn't realize you were referring to an indexed query. Yes >> that could improve performance of the initial retrieval. I am not as >> familiar with indexed query, but I don't know if it lends itself well >> to the individual filtering that is done as each event is fired. I >> think this needs to be discussed/investigated further. > > Ok. How do we go about this ? JIRA ? Different email thread?
I would suggest both. We can probably also get some time to discuss this at the F2F in a few months, unless you think this is more critical? I am just thinking this feature might be a bit too late to get into 7.0 at this point. > > _______________________________________________ > 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
