On Feb 17, 2014, at 5:36 PM, Galder Zamarreño <gal...@redhat.com> wrote:
> > On 31 Jan 2014, at 09:28, Emmanuel Bernard <emman...@hibernate.org> wrote: > >> >> >>> On 30 janv. 2014, at 20:51, Mircea Markus <mmar...@redhat.com> wrote: >>> >>> >>>> On Jan 30, 2014, at 9:42 AM, Galder Zamarreño <gal...@redhat.com> wrote: >>>> >>>> >>>>> On Jan 21, 2014, at 11:52 PM, Mircea Markus <mmar...@redhat.com> wrote: >>>>> >>>>> >>>>>> On Jan 15, 2014, at 1:42 PM, Emmanuel Bernard <emman...@hibernate.org> >>>>>> wrote: >>>>>> >>>>>> By the way, people looking for that feature are also asking for a >>>>>> unified Cache API accessing these several caches right? Otherwise I am >>>>>> not fully understanding why they ask for a unified query. >>>>>> Do you have written detailed use cases somewhere for me to better >>>>>> understand what is really requested? >>>>> >>>>> IMO from a user perspective, being able to run queries spreading several >>>>> caches makes the programming simplifies the programming model: each cache >>>>> corresponding to a single entity type, with potentially different >>>>> configuration. >>>> >>>> Not sure if it simplifies things TBH if the configuration is the same. >>>> IMO, it just adds clutter. >>> >>> Not sure I follow: having a cache that contains both Cars and Persons sound >>> more cluttering to me. I think it's cumbersome to write any kind of >>> querying with an heterogenous cache, e.g. Map/Reduce tasks that need to >>> count all the green Cars would need to be aware of Persons and ignore them. >>> Not only it is harder to write, but discourages code reuse and makes it >>> hard to maintain (if you'll add Pets in the same cache in future you need >>> to update the M/R code as well). And of course there are also different >>> cache-based configuration options that are not immediately obvious (at >>> design time) but will be in the future (there are more Persons than Cars, >>> they live longer/expiry etc): mixing everything together in the same cache >>> from the begging is a design decision that might bite you in the future. >>> >>> The way I see it - and very curious to see your opinion on this - following >>> an database analogy, the CacheManager corresponds to an Database and the >>> Cache to a Table. Hence my thought that queries spreading multiple caches >>> are both useful and needed (same as query spreading over multiple tables). >> >> I know Sanne and you are keen to have one entity type per cache to be able >> to fine tune the configuration. I am a little more skeptical but I don't >> have strong opinions on the subject. >> >> However, I don't think you can forbid the case where people want to store >> heterogenous types in the same cache: >> >> - it's easy to start with >> - configuration is indeed simpler >> - when you work in the same service with cats, dogs, owners, addresses and >> refuges, juggling between these n Cache instances begins to be fugly I >> suspect - should write some application code to confirm >> - people will add to the grid types unknown at configuration time. They >> might want a single bucket. > > +100 Totally agreed, there's no plan to forbid people storing heterogenous values in the same cache. The discussion at hand was actually the other way around: do we want to allow people to store data in multiple caches? if so we querying across multiple caches makes sense, hence this email. 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
