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
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
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
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
+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
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
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
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
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).
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
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
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:
12 matches
Mail list logo