I understand what you mean now. Even before HEM< the EM could be unwrapped
to a Session, even if the Session was a delegate to EntityManagerImpl, and
EMI was not implementing the Session interface.
On Mon, May 16, 2016 at 5:36 PM, Steve Ebersole wrote:
> API? StoredProcedureQuery#unwrap is a JP
API? StoredProcedureQuery#unwrap is a JPA contract. Its there. You mean
the impl of that? The ability to unwrap StoredProcedureQuery to
ProcedureOutputs has been there for some time. Its in 5.0 at least.
On Mon, May 16, 2016 at 9:22 AM Vlad Mihalcea
wrote:
> Maybe the API has changed on mas
Maybe the API has changed on master, I'll check it tomorrow when I
integrate my pending PRs.
Vlad
On Mon, May 16, 2016 at 5:11 PM, Steve Ebersole wrote:
> No, I mean what I said :)
>
> StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs
>
>
> On Mon, May 16, 2016 at 8:56 AM Vlad Mihal
No, I mean what I said :)
StoredProcedureQueryImpl#unwrap accounts for ProcedureOutputs
On Mon, May 16, 2016 at 8:56 AM Vlad Mihalcea
wrote:
> Hi,
>
> You are right. I forgot this is a JPA interface. You mean we need to cast
> it to the Impl class and get the ProcedureOutput from there:
>
> sp
Hi,
You are right. I forgot this is a JPA interface. You mean we need to cast
it to the Impl class and get the ProcedureOutput from there:
spq.unwrap( StoredProcedureQueryImpl.class ).getProcedureOutputs().close()
Vlad
On Mon, May 16, 2016 at 4:24 PM, Steve Ebersole wrote:
> I think it is rea
I think it is reasonable to have have an ability to release the underlying
CallableStatement. I think its a matter of how and where to expose that
though. StoredProcedureQuery is a JPA contract, so we can't add it there.
Also StoredProcedureQueryImpl is an internal class and we generally
discoura
