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
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team