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

There also is the opposite problem to be considered, as Emmanuel suggested on 11/04/2012: you can't forbid the user to store the same object (same type and same id) in two different caches, where each Cache might be using different indexing options. If the "search service" is a global concept, and you run a query which matches object X, we'll return it to the user but he won't be able to figure out from which cache it's being sourced: is that ok?

Ultimately this implies a query might return the same object X in multiple positions in the result list of the query; for example it might be the top result according to some criteria but also be the 5th result because of how it was indexed in a different case: maybe someone will find good use for this "capability" but I see it primarily as a source of confusion.

Finally, if we move the search service as a global component, there might be an impact in how we explain security: an ACL filter applied on one cache - or the index metadata produced by that cache - might not be applied in the same way by an entity being matched through a second cache. Not least a user's permission to access one cache (or not) will affect his results in a rather complex way.

I'm wondering if we need to prevent such situations. Sanne On 25 February 2014 16:24, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: > > On Feb 25, 2014, at 3:46 PM, Adrian Nistor <anistor(a)gmail.com&gt; wrote: > >> They can do what they please. Either put multiple types in one basket or put them in separate caches (one type per cache). But allowing / recommending is one thing, mandating it is a different story. >> >> There's no reason to forbid _any_ of these scenarios / mandate one over the other! There was previously in this thread some suggestion of mandating the one type per cache usage. -1 for it > > Agreed. I actually don't see how we can enforce people that declare Cache<Object,Object> not put whatever they want in it. Also makes total sense for smaller caches as it is easy to set up etc. > The debate in this email, the way I understood it, was: are/should people using multiple caches for storing data? If yes we should consider querying functionality spreading over multiple caches. > >> >> >> >> On Tue, Feb 25, 2014 at 5:08 PM, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >> >> On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >>>> On 24 févr. 2014, at 17:39, Mircea Markus <mmarkus(a)redhat.com&gt; wrote: >>>> >>>> >>>>> On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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. >> >> >> Cheers, >> -- >> Mircea Markus >> Infinispan lead (www.infinispan.org) >> >> >> >> >> > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev