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 <emman...@hibernate.org> wrote:
>
>> On Mon 2014-02-17 18:43, Galder Zamarreño wrote:
>>
>>> On 05 Feb 2014, at 17:30, Emmanuel Bernard <emman...@hibernate.org> wrote:
>>>
>>>> On Wed 2014-02-05 15:53, Mircea Markus wrote:
>>>>
>>>>> On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <emman...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
