On Feb 26, 2014, at 2:33 PM, Adrian Nistor <anis...@redhat.com> wrote:
> On 02/26/2014 04:20 PM, Mircea Markus wrote: >> On Feb 26, 2014, at 2:13 PM, Dan Berindei <dan.berin...@gmail.com> wrote: >> >>> >>> >>> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus <mmar...@redhat.com> wrote: >>> >>> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero <sa...@infinispan.org> 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'm not talking about the current API here, just looking for a way to be able to specify the source cache for an object in the result. We should be able to do that through the query, or if the result is an alternative we can consider it. > 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. I wouldn't mind that, but TBH i think we should add it only if users ask for it. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
