On Feb 25, 2014, at 5:08 PM, Sanne Grinovero <sa...@infinispan.org> wrote:
> 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? Can't the user figure that out based on the way the query is built? I mean the problem is similar with the databases: if address is both a table and an column in the USER table, then it's the query (select) that determines where from the address is returned. > > 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. Curious if this cannot be source of data can/cannot be specified within the query. > 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'll let Tristan comment more on this, but is this really different from an SQL database where you grant access on individual tables and run a query involving multiple of them? > > I'm wondering if we need to prevent such situations. > > Sanne > > On 25 February 2014 16:24, Mircea Markus <mmar...@redhat.com> wrote: >> >> On Feb 25, 2014, at 3:46 PM, Adrian Nistor <anis...@gmail.com> 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 <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. >>> >>> >>> Cheers, >>> -- >>> Mircea Markus >>> Infinispan lead (www.infinispan.org) >>> >>> >>> >>> >>> >> >> 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 > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev 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
