Re: [infinispan-dev] Design change in Infinispan Query

On 02/26/2014 04:20 PM, Mircea Markus wrote: > On Feb 26, 2014, at 2:13 PM, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > >> >> >> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >> >> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero <sanne(a)infinispan.org&gt; wrote: >> >>> There also is the opposite problem to be considered, as Emmanuel >>> suggested on 11/04/2012: >>> you can't forbid the user to store the same object (same type and same >>> id) in two different caches, where each Cache might be using different >>> indexing options. >>> >>> If the "search service" is a global concept, and you run a query which >>> matches object X, we'll return it to the user but he won't be able to >>> figure out from which cache it's being sourced: is that ok? >> Can't the user figure that out based on the way the query is built? >> I mean the problem is similar with the databases: if address is both a table and an column in the USER table, then it's the query (select) that determines where from the address is returned. >> >> You mean the user should specify the cache name(s) when building the query? > yes Let's say multiple caches are specified when building the query. How can I tell (with current result api) where does the matching entity come from?

I still think we should extend the result api in order to provide: 1. the key of the entity, 2. the name of the originating cache. The old result api that just gives you an Iterator<Object> over the matches should continue to exist because it's more efficient for the cases when the user does not need #1 and #2.