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