Provide Query::getDetachedResultStream as variant of Query::getResultStream

[quaff]

The main purpose of Query::getResultStream is avoiding to return a large List which may lead to OOM, but the entities still exist in persistence context and cannot be recycled by GC, we have to detach entity after it consumed from Stream to fix that.

It would be great if JPA provide a detached version of Query::getResultStream, we could attach those entities manually if necessary.

More background: spring-projects/spring-data-jpa#3295

[gavinking]

It's not very clear, but I understand that what you are asking for is a stream that returns detached entities. This is not the programming model of the (stateful) EntityManager. You can of course achieve the effect via use of detach() or clear().

On the other hand, for JPA 4 we plan (#374) to introduce some sort of StatelessEntityManager, similar in concept to Hibernate's StatelessSession, which always returns detached entities from its methods. That's much more powerful than what's proposed here (though of course it's a lot more work).

So I'm inclined to close this issue.

[quaff]

You can of course achieve the effect via use of detach() or clear().

Yes, but it's better that standard API detach them automatically, maybe provide a overloading method Query.getResultStream(boolean detaching).

On the other hand, for JPA 4 we plan (#374) to introduce some sort of StatelessEntityManager

This proposal is trivial and friendly to legacy code since EntityManager is already there, we doesn't need to inject/construct another stateless EntityManager.

[gavinking]

This idea has not grown on me. Where does it end? Do we need getDetachedResultList() as well as getDetachedResulStream()? Do we also need findDetached() on EntityManager.

I would much prefer to provide something truly complete and well-defined in JPA 4 than do something arbitrary and half-baked in JPA 3.

I'm going to close the issue for now. If @lukasj disagrees, I'll reopen it.