On 25 Feb 2014, at 16:08, Mircea Markus <mmar...@redhat.com> wrote: > > On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard <emman...@hibernate.org> wrote: > >>> On 24 févr. 2014, at 17:39, Mircea Markus <mmar...@redhat.com> wrote: >>> >>> >>>> On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard <emman...@hibernate.org> >>>> 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. >>> >>> Curious to hear the whole story :-) >>> We cannot mandate all the suers to use OGM though, one of the reasons being >>> OGM is not platform independent (hotrod). >> >> Then solve all the issues I have raised with a magic wand and come back to >> me when you have done it, I'm interested. > > People are going to use infinispan with one cache per entity, because it > makes sense: > - different config (repl/dist | persistent/non-persistent) for different data > types > - have map/reduce tasks running only the Person entires not on Dog as well, > when you want to select (Person) where age > 18 > I don't see a reason to forbid this, on the contrary. The way I see it the > relation between (OGM, ISPN) <=> (Hibernate, JDBC). Indeed OGM would be a > better abstraction and should be recommended as such for the Java clients, > but ultimately we're a general purpose storage engine that is available to > different platforms as well. >
I do disagree on your assessment. I did write a whole essay on why I think your view is problematic - I was getting tired of repeating myself ;P https://github.com/infinispan/infinispan/wiki/A-continuum-of-data-structure-and-query-complexity To anecdotally answer your specific example, yes different configs for different entities is an interesting benefit but it has to outweigh the drawbacks. If you have to do a map reduce for tasks so simple as age > 18, I think you system better have to be prepared to run gazillions of M/R jobs. I think that Dogs and any domestic animal is fundamentally related to humans - Person in your case. So queries involving both will be required - a cross cache M/R is not doable today AFAIK and even if it was, it’s still M/R and all its drawbacks. To me, the Cache API and Hot Rod are well suited for what I call self contained object graph (i.e. where Dog would be an embedded object of Person and not a separate Entity). In that situation, there is a single cache. One cache per entity does make sense for API that do support what I call connected entities. Hibernate OGM specifically. But please read the wiki page first before commenting. I did spend a lot of time on it https://github.com/infinispan/infinispan/wiki/A-continuum-of-data-structure-and-query-complexity Emmanuel _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
