On Tue 2014-02-18 13:27, Sanne Grinovero wrote: > On 18 February 2014 13:01, Emmanuel Bernard <emman...@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 = "emman...@hibernate.org" select key(user), user from User user where user.email = "emman...@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. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev