We did discuss something like
cache.using(QueryableCache.class).createQuery("...").[build].list();
With some service locator system to have extensible and pluggable modules.
We did discuss a potential problem but I forgot what it was.
Emmanuel
On 20 Apr 2017, at 14:08, Tristan Tarrant <ttarrant(a)redhat.com>
wrote:
Querying an Infinispan cache is currently a bit cumbersome. There are
two paths:
Ickle:
Search.getQueryFactory(cache).create("...").list();
DSL (one possible example):
Search.getQueryFactory(cache).from(class).[filters].build().list();
Ideally we should have something like:
Ickle:
cache.query("...").list();
DSL:
cache.query(class).[filters].list();
Additionally, the query module is separate from infinispan-core. While
this made sense when we didn't have non-indexed query capabilities (and
is somewhat mitigated by the uberjars), I feel that query should be a
1st class citizen API-wise.
For this reason I propose that we extract the query API to
infinispan-commons, put the query SPI in infinispan-core together with
the non-indexed implementation and have the hibernate-search backend as
a pluggable implementation.
Thoughts ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev