Re: [infinispan-dev] Design change in Infinispan Query

On 18 February 2014 13:01, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > On Tue 2014-02-18 14:02, Adrian Nistor wrote: >> There were some points raised previously like /"if you search for more than >> one cache transparently, then you probably need to CRUD for more than one >> cache transparently as well"/. In the SQL world you would also probably CRUD >> against a table or set of tables and then query against a view - a bit like >> what we're doing here. I don't see any problem with this in principle. There >> is however something currently missing in the query result set API - it >> currently does not provide you the keys of the matching entities. People > > Really? I think we have the info in the index at least when the > "ProvidedId" and the keys are the same. We have this info in the engine, but the results to the user don't usually include the keys. For some this is a bit unnatural: a different perspective would be to return _only_ the keys and avoid doing the lookup. We provide a "LazyIterator" on the results which fetches only each matching entry on demand, which I think covers a good deal of use cases but there might be other usages for these keys. I would be great if we had Lambda support to allow users to say what they want us to do with the resultset, rather than fetching it.