Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Sanne Grinovero
On 20 April 2017 at 21:31, Emmanuel Bernard wrote: > We did discuss something like > > cache.using(QueryableCache.class).createQuery("...").[build].list(); > > With some service locator system to have extensible and pluggable modules. > > We did discuss a potential problem

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Emmanuel Bernard
We did discuss something like cache.using(QueryableCache.class).createQuery("...").[build].list(); With some service locator system to have extensible and pluggable modules. We did discuss a potential problem but I forgot what it was. Emmanuel > On 20 Apr 2017, at 14:08, Tristan Tarrant

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Adrian Nistor
If we are discussing how an Ickle query is defined, I insist we need identical APIs. I don't want to go over the long list of benefits of that. Let's just say it's trivial to implement because It's done already :). And now we also have a string dsl, which makes it even easier. We do not have

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Dan Berindei
On Thu, Apr 20, 2017 at 5:06 PM, Tristan Tarrant wrote: > On 20/04/2017 15:34, Dan Berindei wrote: >>> >>> How big is the DSL API surface (which will be brought into commons)? >> >> >> -1 from me to add anything in commons, I don't think allowing the >> users to query both

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Adrian Nistor
+1 for interchangeable apis +1 for infinispan-api module On 04/20/2017 05:06 PM, Tristan Tarrant wrote: > On 20/04/2017 15:34, Dan Berindei wrote: >>> How big is the DSL API surface (which will be brought into commons)? >> -1 from me to add anything in commons, I don't think allowing the >> users

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Tristan Tarrant
On 20/04/2017 15:34, Dan Berindei wrote: >> How big is the DSL API surface (which will be brought into commons)? > > -1 from me to add anything in commons, I don't think allowing the > users to query both embedded caches and remote caches with the same > code is that important. I'd rather go the

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Sanne Grinovero
On 20 April 2017 at 13: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

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread 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

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Dan Berindei
On Thu, Apr 20, 2017 at 3:56 PM, 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).

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread 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

Re: [infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Sanne Grinovero
Looks good to me, at high level. This will have to focus on the capabilities of the non-indexed query engine though, as we won't be able to expose the more advanced capabilities over the DSL without introducing an hard dependency on Hibernate Search. Conversely, the method accepting an Ickle

[infinispan-dev] Infinispan Query API simplification

2017-04-20 Thread Tristan Tarrant
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: