[infinispan-dev] Design change in Infinispan Query

[Mircea Markus]

On Feb 26, 2014, at 2:33 PM, Adrian Nistor <anistor at redhat.com> wrote:

> On 02/26/2014 04:20 PM, Mircea Markus wrote:
>> On Feb 26, 2014, at 2:13 PM, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>>> 
>>> 
>>> On Wed, Feb 26, 2014 at 3:12 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>>> 
>>> On Feb 25, 2014, at 5:08 PM, Sanne Grinovero <sanne at 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)