On 20 April 2017 at 21:31, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
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.
The problem is that apparently people don't like having to know that.
It's very similar to today's Search helper? In that case we might as
well keep things as they are.
Thanks,
Sanne
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev