[infinispan-dev] Infinispan Query API simplification

[Radim Vansa]

That's completely opposite approach from the one outlined for 
distributed counters and other "on-top" functionality (the same approach 
was later suggested for conflict resolution manager, multimap and maybe 
others). Why is query 1st level citizen and those others are not?

I am not opposing the idea but let's define the line between patriarchs 
and plebeians.

How big is the DSL API surface (which will be brought into commons)?

R.

On 04/20/2017 02:08 PM, Tristan Tarrant 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
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team