Great that was actually my thought as well. Anyone else?
On Fri, May 25, 2018, 12:03 AM Vlad Mihalcea <mihalcea.v...@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 <st...@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.v...@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, <st...@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@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>> > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev