Streams API for query result processing.

Description

The Query class could introduce the #stream() method for processing the result on the application level. Eventually this might be similar functionality as the Hibernate filter API provides.

e.g.
{code]
List<Event> events = session.createQuery("from Event")
.stream()
.filter(e -> e.getTitle == "Java 8") // does some optional filtering or any other operation on the result set
.collect(Collectors.toList())

causes

relates to

Activity

Show:

Steve Ebersole May 13, 2016 at 12:15 PM

Initial implementation pushed to master

Steve Ebersole May 10, 2016 at 1:49 PM

If we were to do that second part, I'd prefer to wait on that for 6.0 and SQM. Specifically if we were to do this, I'd much rather see those lambda expressions be interpreted to SQM rather than an intermediate form (HQL, etc)

Steve Ebersole May 10, 2016 at 1:43 PM
Edited

I think we all agree that this should be limited-to/backed-by ScrollableResults.

As far as a dedicated Query#stream() method, the only real benefit I see is to more generically define the return type from #scroll(). So ScrollableResults would be a Stream, #stream() would simply call #scroll().

As far as the rest you bring up (Speedment, lambda expressions, etc) I'd personally think that is better implemented as an extension of the Hibernate Session#createFilter() capability if we were to fully materialize support for that. #createFilter() currently focuses on persistent collections. We would need to also allow streaming from an entity as well:

Stream Entity Example

Stream Persistent Collection Example

Gunnar Morling May 10, 2016 at 9:09 AM

Btw. Speedment is a tool bringing "smart streams" to the table: http://minborgsjavapot.blogspot.de/2015/10/java-8-query-databases-using-streams.html. They convert the given Lambda expressions and other API invocations such as sort() into corresponding parts of a SQL query which then is executed. That happens by means of symbolic execution, I suppose.

Gunnar Morling May 10, 2016 at 9:05 AM

My experiences with Stream are limited, not sure what'd be the best.

Eagerly fetching all results into a list should be avoided, so the implementation of session.createQuery("from Event").stream() should be backed by scrollable results in one way or another.

I.e. the following should not fetch all events but only so many to find the first matching one and then not consume the result iterator any more:

Fixed

Assignee

Steve Ebersole

Reporter

Labels

Time tracking

9.27h logged

Fix versions

Priority

Created August 15, 2014 at 8:17 PM
Updated April 17, 2018 at 7:09 PM
Resolved May 13, 2016 at 12:15 PM