[infinispan-dev] Infinispan Query API simplification

[Tristan Tarrant]

Actually, the API for counters et alia is going into commons (so that it 
can be shared between embedded and remote). Additionally, something like 
a counter has no API relationship with a Cache, whereas query does.

Tristan

On 20/04/2017 14:56, Radim Vansa wrote:
> 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
>>
> 
> 

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat