[hibernate-dev] Multiple ResultSets from JDBC execution

[Steve Ebersole]

Great that was actually my thought as well.

Anyone else?


On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I think that by default we should not assume the result sets are the same.
>
> Only if we provide a certain QueryHint (JPA) or call a specific method
> (Hibernate API) should we instruct Hibernate to process all ResultSets, in
> the same way, using a single ResultSetMapping.
>
> Vlad
>
>
>
> On Fri, May 25, 2018 at 12:15 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I'm not saying to have a single result over all of the result
>> types/mappings.  I am questioning whether the proper interpretation is to
>> uniformly process all result sets (assuming all result sets have same
>> columns and domain results) versus one per ResultSet.
>>
>> E.g, let's say we have a ProcedureCall that returns 2 ResultSets that
>> each should return some scalar value, lets say an Integer... Would this
>> require passing 2 result set mappings (the same one twice), one per
>> ResultSet.  Or should use be able to just pass one mapping and have us
>> apply that one to each ResultSet?
>>
>> I think there are cases where both might make sense.
>>
>>
>>
>> On Thu, May 24, 2018, 2:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> I this Hibernate forum discussion is on the same topic:
>>>
>>>
>>> https://discourse.hibernate.org/t/oracle-stored-procedure-with-multiple-out-ref-cursors/782
>>>
>>> So, if we have multiple REF_CURSOR sent back from a stored procedure,
>>> should we allow getResultList to be called multiple times, right?
>>>
>>> I don't think we should aggregate those to a single List<Object []> and
>>> allow a single getResultList call.
>>>
>>> Vlad
>>>
>>> On Wed, 23 May 2018, 15:52 Steve Ebersole, <steve at hibernate.org> wrote:
>>>
>>>> Execution of procedure calls, function calls and anonymous blocks can
>>>> all
>>>> lead to JDBC returning us multiple ResultSets.
>>>>
>>>> To account for this (for the first 2 anyway) JPA allows defining
>>>> multiple
>>>> ResultSetMapping references for the StoredProcesdureQuery.
>>>> Alternatively,
>>>> it allows specifying multiple "result classes".  However, JPA is
>>>> silently
>>>> on how a provider is to treat these.  Specifically, are these
>>>> "aggregated"
>>>> into a single "row reader"?  Or do they represent individual row readers
>>>> specific to each expected ResultSet?  In other words, are the ResultSets
>>>> heterogeneous or homogeneous?
>>>>
>>>> At the moment, Hibernate treats these by building a single aggregated
>>>> row
>>>> reader that it applies to reading all ResultSets.  Like I said, JPA is
>>>> silent on what this "means" (and the TCK does not test it) so we are
>>>> free
>>>> to interpret this as we see fit.
>>>>
>>>> In retrospect I think the multiple ResultSetMappping case is probably
>>>> best
>>>> interpreted using the "distinct row reader per ResultSet" approach.  I'm
>>>> not so convinced that is always the best interpretation of the multiple
>>>> result classes case.  But I also think these should probably be handled
>>>> consistently.
>>>>
>>>> So what is everybody's preference here?  Which interpretation do we
>>>> pick?
>>>> Worth it to make this configurable (per-SF + per-Query)?
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>