[infinispan-issues] [JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

[Radim Vansa (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406117#comment-13406117 ] 

Radim Vansa commented on ISPN-3795:
-----------------------------------

[~gustavonalle] +1 If we'll index only on the primary owner, the place between EWI and xDI is sufficient (primary can always read the value), however if we want to keep ALL for replicated case, we need to have it after xDI so that the value is loaded from remote node if it's not present currently.

However, in some situations the value is not loaded from persistence/remote node. While some flags can be expected to be dangerous {{IGNORE_RETURN_VALUE}} is documented to be a safe option at all times, and we should keep it that way. So, should we somehow enforce loading (that enforce flag would be set above EWI) even if the operation itself doesn't require it?

> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
>                 Key: ISPN-3795
>                 URL: https://issues.jboss.org/browse/ISPN-3795
>             Project: Infinispan
>          Issue Type: Bug
>          Components: Embedded Querying
>    Affects Versions: 6.0.0.Final
>            Reporter: Dan Berindei
>            Assignee: Gustavo Fernandes
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)