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 query will have to fail at runtime if it's using full-text capabilities and the indexing engine wasn't enabled. I think that's fine, as it's not wildly different than attempting a full-text query today when having the wrong fields indexed: we can only validate such things when the query is parsed. [N.B. I'd like to see a way to pre-register queries - like "prepared statement", for many other good reasons so that might improve eventually] So the tricky part will be to cleanly separate the query API from the full-text query API, and the downside will be that using full-text queries will still require some form of API unwrapping. I take it you'd like to see the same API which we'll make for Cache to be exposed on Remote Cache ? Thanks, Sanne On 20 April 2017 at 13:08, Tristan Tarrant <ttarrant(a)redhat.com&gt; wrote:

On Thu, Apr 20, 2017 at 3:56 PM, Radim Vansa <rvansa(a)redhat.com&gt; wrote: 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. -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

+1 for interchangeable apis +1 for infinispan-api module On 04/20/2017 05:06 PM, Tristan Tarrant wrote:

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 20 April 2017 at 13:56, Radim Vansa <rvansa(a)redhat.com&gt; wrote: I agree this needs to be clarified. Be aware that this is the main reason for which it didn't happen earlier ;-) It seems what changed recently is the demand for nicer Query API is quite popular, but I'm skeptical that our existing helper is so hard to use; are we sure people won't just be fine with us improving that API but still keeping the helper? Maybe just a lack of straight forward examples? Either way, it would still be good to draft some guidelines for future API development. Maybe even just having a quick reference sheet with all extension using the unwrap would make Query users happier. ## Alternative direction: what about we actually simplify the Cache API in Infinispan Core, and move anything which isn't strictly key/value store access to its own module - to be accessed via unwrap. This would allow people who need just the Cache to run that directly, so good for integrators - I'm thinking use cases like Hibernate's simple caching and WildFly's clustering needs. Then we introduce a new module which depends on all of these and exposes a nicer API. People using Infinispan "directly" would use this, and specific system integrators could use the composition they prefer by picking only the fragments they want/need. It's one method on Cache to get started ;) I have no idea how large it is going to be: surely not trivial but I don't see that as a problem as in term of "fluent API" the IDE will guide you from the single starting point. It needs to support several options, hints, flags and not just "list()" but also streams, and reusing a Query definition as filter for other purposes. Finally the fact that one might want to query for projections, keys and combinations makes even the return type non-trivial.

On 20 April 2017 at 21:31, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: The problem is that apparently people don't like having to know that. It's very similar to today's Search helper? In that case we might as well keep things as they are. Thanks, Sanne