db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1288) Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
Date Thu, 04 May 2006 20:44:17 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377886 ] 

Rick Hillegas commented on DERBY-1288:
--------------------------------------

Mousing in Lance's response:

>
>
>    [ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377874 ]

>
>Daniel John Debrunner commented on DERBY-1288:
>----------------------------------------------
>
>
>dan >> If multiple result sets are returned when should any error be thrown, before
the execution starts or once the system detects that multiple result sets are returned?
>
>lance > This would probably be implementation defined depending on the mechanism being
used.
>
>This is where I get confused, if this is implementation defined then how can returning
a single ResultSet not be implementation defined as well? Is there a good clear definition
of the behaviour you would like to see?
>  
>
I am not sure how JDBC can guarantee when/how a driver/backend determines whether a ResultSet
or an update count (or both) is coming down the wire especially given some vendors support
java based procedures, standard stored procedures.

>As an example, if the behaviour is implementation defined then it seems to me that a procedure
that was defined with DYNAMIC RESULT SETS 4 could be rejected at compile time, even though
it could at runtime only return a single result set. This seems a valid implementation
>  
>
possibly but there is no way to determine this on vendors such as Sybase/MS SQL Server with
t-sql procedures

>Similarly a procedure defined with DYNAMIC RESULT SETS 1 could return zero result sets,
and thus the executeQuery() has to thrown an exception.
>
>As I've said in DERBY-501, section 13.3.3.3 of JDBC 3.0 states:
>"If the type or number of results returned by a CallableStatement object are not
>known until run time, the CallableStatement object should be executed with the
>method execute."
>  
>
agree but the wording above has nothing to do with the J2EE requirement which has been there
as i said since the J2EE 1.2 spec.  All i have done is move the wording from the J2EE spec
to the compliance section of the JDBC 4 spec and start pruning things that are already required.

Now myself, i always use execute() with my sprocs but that is me.


>Now with Derby Java procedures, the engine does *not* know until runtime how many ResultSets
are returned, so it seems to me that this implies execute() must be used and so executeQuery
is invalid.
>Maybe I'm reading this the wrong way, and "known" applies to the knowledge of the application
developer
>and not the driver/database engine?
>  
>
In this case it would apply to the application developer.  So the intent is that the developer
using a sproc with a stored procedure would only choose executeQuery() when they can guarantee
a single ResultSet down the wire and executeUpdate() when no ResultSets will be sent down
the wire and use execute() otherwise.



> Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
> ----------------------------------------------------------------------------------------------
>
>          Key: DERBY-1288
>          URL: http://issues.apache.org/jira/browse/DERBY-1288
>      Project: Derby
>         Type: Improvement

>   Components: JDBC
>     Versions: 10.2.0.0
>     Reporter: Rick Hillegas
>      Fix For: 10.2.0.0

>
> The following statement raises an error in Derby:
>   statement.executeQuery( "{call foo()}" );
> although this statement works:
>   statement.executeUpdate( "{call foo()}" );
> According to section 6.4 of the latest draft of the JDBC4 Compliance chapter, both statements
are supposed to work in order to claim Java EE JDBC Compliance.
> We need to bring Derby into compliance by supporting executeQuery() on escaped procedure
invocations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message