Linda,
Now I'm confused between your two responses on this topic... Should
getUpdateCount implicitly execute the prepared statement (similar to
getSingleResult and getResultList)? Or, should the user be required to
call execute() before calling getUpdateCount()? Depending on your answer,
I may have follow observations... :-) Thanks.
-- Kevin
Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 08/06/2013 02:48:00
PM:
> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> To: jsr338-experts_at_jpa-spec.java.net,
> Date: 08/06/2013 02:49 PM
> Subject: [jsr338-experts] Re: StoredProcedure clarification
>
> Gordon is right here, so please excuse my jet-lagged response.
> I had misread getUpdateCount for executeUpdate (which should have
> been called).
>
> -Linda
>
>
> On 8/6/2013 12:31 PM, gordon yorke wrote:
> > The practical thing to do for users in this case is to execute the
> stored procedure but the specification does not
> > define what should happen if getUpdateCount() is called on an
> unexecuted StoredProcedureQuery.
> > --Gordon
> >
> > On 26/07/2013 7:16 PM, Steve Ebersole wrote:
> >> EntityManager em = ...;
> >> StoredProcedureQuery query = em.createStoredProcedureQuery(...);
> >> query.getUpdateCount();
> >>
> >> What should happen above when getUpdateCount() is called? The
> "result" corollaries (getResultList, getSingleResult)
> >> specifically say that the query will be executed when they are
> called. getUpdateCount conspicuously says nothing on
> >> the subject. Nor does it call out being allowed to throw an
> exception in this case. So should I assume that
> >> getUpdateCount() should just return -1 here?
> >>
> >> Yes, its a silly case, but the TCK does it. Many times...
> >>
> >>
> >
>