If only. I seriously doubt we can get that approach as the solution through the EG, but we'll see
On Mon, Oct 16, 2017, 1:12 PM Robert Marcano <rob...@marcanoonline.com> wrote: > On 10/16/2017 10:13 AM, Steve Ebersole wrote: > > On Mon, Oct 16, 2017 at 9:00 AM Robert Marcano <rob...@marcanoonline.com > > <mailto:rob...@marcanoonline.com>> wrote: > > > > No, I know implicitly closing the JDBC statement is not possible with > > only the current CallableStatement API. There is no way to know if > the > > client code needs or read all possible outputs from the stored > > procedure. My previous email mentioned making CallableStatement an > > AutoCloseable but that will make the API too different from the other > > kind of queries, that you explained better than me, are stateless. > > > > Maybe exposing Hibernate ProcedureOutputs to JPA or > StoredProcedureQuery > > implementing some kind of prepareCall() method that return a stateful > > object that implement AutoCloseable. > > > > > > "Exposing Hibernate ProcedureOutputs to JPA" how? Something beyond the > > `storedProcedureQuery.unwrap( ProcedureOutputs.class )` I mentioned > earlier? > > > > Yes, I think there should be a way to close a StoredProcedureQuery > internal statement without the need to unwrap to a JPA implementation > class. > > An equivalent to ProcedureOutputs added to the JPA spec implementing > AutoCloseable sounds fine to me. > _______________________________________________ > 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