[infinispan-dev] Design change in Infinispan Query

[Emmanuel Bernard]

On Tue 2014-02-18 13:27, Sanne Grinovero wrote:
> On 18 February 2014 13:01, Emmanuel Bernard <emmanuel at hibernate.org> 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.

I was thinking of offering a way to project the key / id

    select key(user) from User user where user.email = "emmanuel at hibernate.org"
    select key(user), user from User user where user.email = "emmanuel at hibernate.org"

If you guys really want, you can add a cache(user) function as well to
project the Cache instance. Looks wrong at first sight though.