[infinispan-dev] Design change in Infinispan Query

[Mircea Markus]

On Feb 18, 2014, at 12:02 PM, Adrian Nistor <anistor at redhat.com> wrote:

> Well, OGM and Infinispan are different species :) So, Infinispan being what it is today - a non-homogenous, schema-less KV store, without support for entity associations (except embedding) - which simplifies the whole thing a lot, should we or should we not provide transparent cross-cacheManager search capabilities, in this exact context?  Vote?

TBH I think users should push us for this if they need it. -1 to do it right now.

> 
> There were some points raised previously like "if you search for more than one cache transparently, then you probably need to CRUD for more than one cache transparently as well". In the SQL world you would also probably CRUD against a table or set of tables and then query against a view - a bit like what we're doing here.
> I don't see any problem with this in principle. There is however something currently missing in the query result set API - it currently does not provide you the keys of the matching entities.

would be nice to have an option for that, indeed. 

> People work around this by storing the key in the entity.  Now with the addition of the cross-cacheManager search we'll probably need to fix the result api  and also provide a reference to the cache (or just the name?) where the entity is stored.
> 
> The (enforced) one entity type per cache rule is not conceptually or technically required for implementing this, so I won't start raving against it :)  Sane users should apply it however.
> 
> 
> On 02/18/2014 12:13 AM, Emmanuel Bernard wrote:
>> By the way, Mircea, Sanne and I had quite a long discussion about this one and the idea of one cache per entity. It turns out that the right (as in easy) solution does involve a higher level programming model like OGM provides. You can simulate it yourself using the Infinispan APIs but it is just cumbersome.
>> 
>> 
>>> On 17 févr. 2014, at 18:51, Emmanuel Bernard <emmanuel at hibernate.org>
>>>  wrote:
>>> 
>>> 
>>>> On Mon 2014-02-17 18:43, Galder Zamarreño wrote:
>>>> 
>>>> 
>>>>> On 05 Feb 2014, at 17:30, Emmanuel Bernard <emmanuel at hibernate.org>
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>>> On Wed 2014-02-05 15:53, Mircea Markus wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <emmanuel at hibernate.org>
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Sure searching for any cache is useful. What I was advocating is that if you search for more than one cache transparently, then you probably need to CRUD for more than one cache transparently as well. And this is not being discussed. 
>>>>>>> 
>>>>>> Not sure what you mean by CRUD over multiple caches? ATM one can run a TX over multiple caches, but I think there's something else you have in mind :-)
>>>>>> 
>>>>> 
>>>>> //some unified query giving me entries pointing by fk copy to bar and
>>>>> //buz objects. So I need to manually load these references.
>>>>> 
>>>>> //happy emmanuel
>>>>> Cache unifiedCache = cacheManager.getMotherOfAllCaches();
>>>>> Bar bar = unifiedCache.get(foo);
>>>>> Buz buz = unifiedCache.get(baz);
>>>>> 
>>>>> //not so happy emmanuel
>>>>> Cache fooCache = cacheManager.getCache("foo");
>>>>> Bar bar = fooCache.get(foo);
>>>>> Cache bazCache = cacheManager.getCache("baz");
>>>>> Buz buz = bazCache.put(baz);
>>>>> 
>>>> Would something like what Paul suggests in https://issues.jboss.org/browse/ISPN-3640
>>>>  help you better? IOW, have a single cache, and then have a filtered view for Bar or Buz types? Not sure I understand the differences in your code changes in terms of what makes you happy vs not.
>>>> 
>>> Not really.
>>> What makes me unhappy is to have to keep in my app all the
>>> references to these specific cache store instances. The filtering
>>> approach only moves the problem.
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> 
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> 
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)