[infinispan-dev] Infinispan Query API simplification

[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 ATM a unified way of executing an Ickle query. As Tristan 
showed in the mail starting this thread, the incantations are slightly 
different. And I'd like to have that unified too.

The BasicCache/RemoteCache mishap is a textbook demonstration of a leaky 
abstraction, and is unrelated.  Should not stop us from unifying query 
execution. But I would probably not add a 'query' method to the cache 
interfaces and would rather go with something similar to what Sanne 
proposed in a previous email in this thread (the so called 'Alternative 
direction').

On 04/20/2017 08:35 PM, Dan Berindei wrote:
> On Thu, Apr 20, 2017 at 5:06 PM, Tristan Tarrant <ttarrant at redhat.com> 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 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.
>>
>> Actually, we've had requests for interchangeable APIs...
>>
>> So, according to your strategy we either have each feature implemented with
>> a divergent specific embedded or remote API, or each feature has its own
>> feature-api with two separate feature-embedded and feature-remote
>> implementations. Both plans sound terrible.
>>
> Would a divergent embedded vs remote API be that bad? If the
> functionality really is different, then I'd rather have different APIs
> then force 2 different things use the same API.
>
> E.g. with BasicCache, IMO it would have been better to focus on the
> versioned conditional write operations, and remove all the
> non-versioned conditional write operations from RemoteCache. I'm sure
> we could have improved the versioned API a lot, but instead we worked
> mainly on the non-versioned API that we got from BasicCache.
>
>> Alternatively, we could go with an infinispan-api package (which Paul has
>> been advocating for a long time) which would contain the various interfaces.
>>
>>
>> Tristan
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev