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 <ttarr...@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@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