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

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes edited comment on ISPN-3795 at 5/15/17 4:48 AM: ------------------------------------------------------------------ [~rvansa] Twofold: * ClusteredQueries, where each node indexes "LOCAL" entries, in its own non-shared local index. During query time the ClusteredQuery API allows to broadcast a query to all nodes, aggregating the results to return to the user. * Shared Index: most widely used, index is shared by all nodes and Index.LOCAL allows to index the entry only once. For both cases above, though, we don't necessarily need Index.LOCAL; we can use Index.PRIMARY_OWNER that the effect will be the same, actually more efficiently: we don't need to fetch values remotely from non-owner. So I think we could get rid of Index.LOCAL, map it internally to Index.PRIMARY_OWNER and move the QI after the EWI that the context would always be available was (Author: gustavonalle): [~rvansa] Twofold: * ClusteredQueries, where each node indexes "LOCAL" entries, in its own non-shared local index. During query time the ClusteredQuery API allows to broadcast a query to all nodes, aggregating the results to return to the user. * Shared Index: most widely used, index is shared by all nodes and Index.LOCAL allows to index the entry only once. For both cases above, though, we don't necessarily need Index.LOCAL; we can use Index.PRIMARY_OWNER that the effect will be the same, actually more efficiently: we don't need to fetch values remotely from non-owner. So I think we could get rid of Index.LOCAL, and put the QI after the EWI that the context would always be available -- This message was sent by Atlassian JIRA (v7.2.3#72005)