On Thu, Apr 20, 2017 at 3:56 PM, Radim Vansa <rva...@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 am not opposing the idea but let's define the line between patriarchs
> and plebeians.
I think you meant patricians, not patriarchs :)
But your question makes sense, especially as Sanne pointed out that
some query functionality will not be available via the commons/core
API.
>
> 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 opposite way and remove the
BasicCache interface completely.
Dan
>
> 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 <rva...@redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
