> On May 5, 2017, at 4:39 PM, Linda DeMichiel <linda.demichiel_at_oracle.com> wrote:
>
> OK, thanks for your perspective. I am trying to do due diligence
> with regard to the portability aspects here.
Understand. There is always going to be a bit of uniqueness, just like with JDBC drivers.
>
> I must admit I am on the fence, but I am ok with adding these
> methods to the spec.
Thing to keep in mind is that a user can basically do this already given the results are in a List so .stream() is already available (which is why the default implementation is trivial).
The advantage of having the method allows the implementation to optimize and still have a consistent API. FWIW, I prefer stream() as the method name as it is consistent with the model for all other api’s which use Streams. When I added a Stream based method to DriverManager to supplement getDrivers(), I went with drivers() as this is the new model for naming…
I know you will do the right thing as always :-)
HTH
>
> -Linda
>
>
> On 5/5/17, 12:52 PM, Steve Ebersole wrote:
>> I would not say that this is "very vendor-specific". Certainly the
>> method leaves a lot of freedom for the provider in terms of
>> implementation, but honestly that is not any different from most other
>> aspects of the JPA APIs. Provider-X might define a far more
>> efficient/performant implementation of any JPA API method as opposed to
>> Provider-Y. I do not see how this one is any different.
>>
>> On Fri, May 5, 2017 at 1:51 PM Linda DeMichiel
>> <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
>>
>> Hi all,
>>
>> To me this still sounds very vendor-specific at this point.
>>
>> Wouldn't it be better to just allow vendors to provide such
>> functionality through the loophole that we currently have -- i.e.,
>> by an unwrap of the Query object into the vendor-specific one.
>>
>> Then once we can agree on some more specific semantics here this
>> can be standardized in a future release.
>>
>> We might want to add an unwrap to TypedQuery as well, but that
>> is trivial enough.
>>
>> -Linda
>>
>>
>> On 5/5/17, 11:40 AM, Lukas Jungmann wrote:
>> > Hi,
>> >
>> >
>> > On 5/4/17 11:35 PM, Linda DeMichiel wrote:
>> >> Hi,
>> >>
>> >> If the value is mostly in the provider-specific add-ons, then I
>> >> think it would be better to wait and standardize in a later
>> >> release.
>> >>
>> >> What did you have in mind here?
>> >
>> > basically provide an API returning a Stream which is not
>> constrained by
>> > some specific characteristics (as Oliver pointed users
>> expectation may
>> > vary here) while still having ability to constrain them, or maybe
>> better
>> > - influence the behaviour of the returned stream through provider
>> > specific QueryHints.
>> >
>> > as for the name of the method - I've chosen 'getResultStream' to be
>> > consistent with existing methods; but I don't mind if I'm over voted
>> > here as long as we have sth like this availiable
>> >
>> > thanks,
>> > --lukas
>> >>
>> >> -Linda
>> >>
>> >>
>> >> On 5/4/17, 1:01 PM, Lukas Jungmann wrote:
>> >>> Hi,
>> >>>
>> >>> another change I'd like to propose is an addition of
>> >>> getResultStream:Stream method to javax.persistence.Query/TypedQuery
>> >>> interfaces with following javadoc and provided with default
>> >>> implementation:
>> >>>
>> >>> javax.persistence.Query:
>> >>>
>> >>> / /**//
>> >>> // * Execute a SELECT query and return the query results//
>> >>> // * as an untyped <code>java.util.Stream</code>.//
>> >>> // * By default this method delegates to
>> >>> <code>getResultList().stream()</code>,//
>> >>> // * however persistence provider may choose to override this
>> >>> method//
>> >>> // * to provide additional capabilities.//
>> >>> // *//
>> >>> // * @return a stream of the results//
>> >>> // * @throws IllegalStateException if called for a Java//
>> >>> // * Persistence query language UPDATE or DELETE
>> statement//
>> >>> // * @throws QueryTimeoutException if the query execution
>> exceeds//
>> >>> // * the query timeout value set and only the
>> statement is//
>> >>> // * rolled back//
>> >>> // * @throws TransactionRequiredException if a lock mode other
>> >>> than//
>> >>> // * <code>NONE</code> has been set and there is no
>> >>> transaction//
>> >>> // * or the persistence context has not been joined
>> to the
>> >>> transaction//
>> >>> // * @throws PessimisticLockException if pessimistic locking//
>> >>> // * fails and the transaction is rolled back//
>> >>> // * @throws LockTimeoutException if pessimistic locking//
>> >>> // * fails and only the statement is rolled back//
>> >>> // * @throws PersistenceException if the query execution
>> exceeds //
>> >>> // * the query timeout value set and the transaction //
>> >>> // * is rolled back //
>> >>> // * @see Stream//
>> >>> // * @see #getResultList()//
>> >>> // * @since 2.2//
>> >>> // *///
>> >>> // default Stream getResultStream() {//
>> >>> // return getResultList().stream();//
>> >>> // }/
>> >>>
>> >>> similarly to javax.persistence.TypedQuery:
>> >>>
>> >>> / /**//
>> >>> // * Execute a SELECT query and return the query results//
>> >>> // * as a typed <code>java.util.Stream</code>.//
>> >>> // * By default this method delegates to
>> >>> <code>getResultList().stream()</code>,//
>> >>> // * however persistence provider may choose to override this
>> >>> method//
>> >>> // * to provide additional capabilities.//
>> >>> // *//
>> >>> // * @return a stream of the results//
>> >>> // * @throws IllegalStateException if called for a Java//
>> >>> // * Persistence query language UPDATE or DELETE
>> statement//
>> >>> // * @throws QueryTimeoutException if the query execution
>> exceeds//
>> >>> // * the query timeout value set and only the
>> statement is//
>> >>> // * rolled back//
>> >>> // * @throws TransactionRequiredException if a lock mode other
>> >>> than//
>> >>> // * <code>NONE</code> has been set and there is no
>> >>> transaction//
>> >>> // * or the persistence context has not been joined
>> to the
>> >>> transaction//
>> >>> // * @throws PessimisticLockException if pessimistic locking//
>> >>> // * fails and the transaction is rolled back//
>> >>> // * @throws LockTimeoutException if pessimistic locking//
>> >>> // * fails and only the statement is rolled back//
>> >>> // * @throws PersistenceException if the query execution
>> exceeds //
>> >>> // * the query timeout value set and the transaction //
>> >>> // * is rolled back //
>> >>> // * @see Stream//
>> >>> // * @see #getResultList()//
>> >>> // * @since 2.2//
>> >>> // *///
>> >>> // default Stream<X> getResultStream() {//
>> >>> // return getResultList().stream();//
>> >>> // }/
>> >>>
>> >>> Do you think this is OK or does it give providers to big freedom?
>> >>>
>> >>> Thank you,
>> >>> --lukas
>> >>>
>> >
>>
<
http://oracle.com/us/design/oracle-email-sig-198324.gif>
<
http://oracle.com/us/design/oracle-email-sig-198324.gif> <
http://oracle.com/us/design/oracle-email-sig-198324.gif>
<
http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen_at_oracle.com <mailto:Lance.Andersen_at_oracle.com>