[infinispan-dev] Design change in Infinispan Query

[Sanne Grinovero]

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 at redhat.com> wrote:
>
> On Feb 25, 2014, at 3:46 PM, Adrian Nistor <anistor at 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 <mmarkus at redhat.com> wrote:
>>
>> On Feb 25, 2014, at 9:28 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> >> On 24 févr. 2014, at 17:39, Mircea Markus <mmarkus at redhat.com> wrote:
>> >>
>> >>
>> >>> On Feb 17, 2014, at 10:13 PM, Emmanuel Bernard <emmanuel at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev