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(a)redhat.com
<mailto:anistor@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev