[infinispan-dev] Optional in listener events

[Adrian Nistor]

I remember there was some discussion to refactor listeners to drop the 
concept of pre-events and have the previous value available in the 
post-event (where applicable). I do not remember what decision was made 
about this. But if we do it, that would be already a big backwards 
incompatible change, so modifying some defaults regarding the behavior 
of the Listener annotation is just mildly disturbing. We'll have to 
apologize/document this anyway and also provide migration advice.

On 08/22/2016 09:15 PM, William Burns wrote:
> I like the idea of having a variable to set on the listener 
> annotation.  This way we can know for sure if we need to force 
> previous values for some listeners and not for others.
>
> It seems the default should be to force the previous value to be more 
> inline with the current behavior, but I fear no one will use the 
> opposite in this case though.  What do you guys think?
>
> On Mon, Aug 22, 2016 at 4:31 AM Adrian Nistor <anistor at redhat.com 
> <mailto:anistor at redhat.com>> wrote:
>
>     Hi Radim,
>
>     Continuous query is built on top of these listeners. CQ _always_ needs
>     the previous value and it is very convenient in this case that the
>     command is forced to load the previous value. I imagine there may be
>     other use cases where we cannot live without the prev value.
>
>     I think the listener should be able to state if it needs the prev
>     value
>     at registration time. Maybe add a new attribute in the Listener
>     annotation? Similar to how we handled Observation.
>
>     Adrian
>
>     On 08/19/2016 11:34 PM, Radim Vansa wrote:
>     > Hi,
>     >
>     > as I am trying to simplify current entry wrapping and
>     distribution code,
>     > I often find that listeners can get wrong previous value in the
>     event,
>     > and it sometimes forces the command to load the value even if it
>     is not
>     > needed for the command.
>     >
>     > I am wondering if we should change the previous value in events to
>     > Optional - we can usually at least detect that we cannot provide a
>     > reliable value (e.g. after retry due to topology change, or
>     because the
>     > command did not bothered to load the previous value from cache
>     loader)
>     > and return empty Optional.
>     >
>     > WDYT?
>     >
>     > Radim
>     >
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160824/a9ba856c/attachment.html