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

On 17 févr. 2014, at 18:51, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > On Mon 2014-02-17 18:43, Galder Zamarreño wrote: > >> On 05 Feb 2014, at 17:30, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >>> On Wed 2014-02-05 15:53, Mircea Markus wrote: >>> >>>> On Feb 3, 2014, at 9:32 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev