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&gt; 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&gt; > 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&gt; 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 >>> >>