Re: [infinispan-dev] Design change in Infinispan Query
On Tue 2014-02-18 14:02, Adrian Nistor wrote:
Well, OGM and Infinispan are different species :) So, Infinispan
being what
it is today - a non-homogenous, schema-less KV store, without support for
entity associations (except embedding) - which simplifies the whole thing a
lot, should we or should we not provide transparent cross-cacheManager
search capabilities, in this exact context? Vote?
Yes it makes sense to do queries like
where name or title = "foo" AND description or content contains
"bar"
over a heterogeneous set (say books and DVDs)
But if you had in mind to do joins between different entries in the
cache, then this would require some cross-cache map reduce and be
inefficient so that's not a good use case.
There were some points raised previously like /"if you search for more than
one cache transparently, then you probably need to CRUD for more than one
cache transparently as well"/. In the SQL world you would also probably CRUD
against a table or set of tables and then query against a view - a bit like
what we're doing here. I don't see any problem with this in principle. There
is however something currently missing in the query result set API - it
currently does not provide you the keys of the matching entities. People
Really? I think we have the info in the index at least when the
"ProvidedId" and the keys are the same.
work around this by storing the key in the entity. Now with the
addition of
the cross-cacheManager search we'll probably need to fix the result api and
also provide a reference to the cache (or just the name?) where the entity
is stored.
Right, I'm not sure Sanne agrees with me yet but you need to store the
cache name in the index. Hibernate Search can reason at query time to
see if it can avoid using this term to speed things up (massively). That
will depend whether or no indexes are shared between caches.