Re: [infinispan-dev] Infinispan Query API simplification
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev