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.

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to