Great that was actually my thought as well.
Anyone else?
On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.vlad(a)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(a)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(a)gmail.com>
> wrote:
>
>> I this Hibernate forum discussion is on the same topic:
>>
>>
>>
https://discourse.hibernate.org/t/oracle-stored-procedure-with-multiple-o...
>>
>> 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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>