Re: [infinispan-dev] Infinispan Query API simplification

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 >