On 22 sept. 2014, at 19:23, William Burns
<mudokonman(a)gmail.com> wrote:
On Fri, Sep 19, 2014 at 12:39 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>
>> On 19 Sep 2014, at 17:09, William Burns <mudokonman(a)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
>> <emmanuel(a)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?