[infinispan-dev] Infinispan Query API simplification

[Sanne Grinovero]

On 20 April 2017 at 13:56, Radim Vansa <rvansa at redhat.com> 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 agree this needs to be clarified. Be aware that this is the main
reason for which it didn't happen earlier ;-)
It seems what changed recently is the demand for nicer Query API is
quite popular, but I'm skeptical that our existing helper is so hard
to use; are we sure people won't just be fine with us improving that
API but still keeping the helper?

Maybe just a lack of straight forward examples?

Either way, it would still be good to draft some guidelines for future
API development.

Maybe even just having a quick reference sheet with all extension
using the unwrap would make Query users happier.

## Alternative direction:

what about we actually simplify the Cache API in Infinispan Core, and
move anything which isn't strictly key/value store access to its own
module - to be accessed via unwrap.

This would allow people who need just the Cache to run that directly,
so good for integrators - I'm thinking use cases like Hibernate's
simple caching and WildFly's clustering needs.

Then we introduce a new module which depends on all of these and
exposes a nicer API. People using Infinispan "directly" would use
this, and specific system integrators could use the composition they
prefer by picking only the fragments they want/need.

> 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)?

It's one method on Cache to get started ;)
I have no idea how large it is going to be: surely not trivial but I
don't see that as a problem as in term of "fluent API" the IDE will
guide you from the single starting point.

It needs to support several options, hints, flags and not just
"list()" but also streams, and reusing a Query definition as filter
for other purposes.
Finally the fact that one might want to query for projections, keys
and combinations makes even the return type non-trivial.

>
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev