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.
Linda DeMichiel <linda.demichiel@...> wrote on 08/06/2013 02:48:00 PM:
> From: Linda DeMichiel <linda.demichiel@...>
> To: jsr338-experts@...,
> 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).
> 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...
[jpa-spec users] [jsr338-experts] Re: StoredProcedure clarification