db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1288) Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
Date Thu, 04 May 2006 20:08:10 GMT


Daniel John Debrunner (JIRA) wrote:
>     [ 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.
>>     
>
>   

Mime
View raw message