db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()
Date Sat, 27 May 2006 11:35:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-501?page=comments#action_12413576 ] 

Knut Anders Hatlen commented on DERBY-501:
------------------------------------------

Thanks, great catch! I had missed that.

This means that a stored procedure is free to return any ResultSet
object, but only the ones that are still open and were created by the
connection which called the stored proc are visible to the user? I
find this, um, fascinating...

For instance, I tried to execute this procedure

    public static void myProc(ResultSet[] rs1, ResultSet rs2[])
        throws SQLException
    {
        rs1[0] =
            DriverManager.getConnection("jdbc:postgresql://localhost/mydb",
                                        "test", "test").
            createStatement().executeQuery("select * from t");
        rs2[0] =
            DriverManager.getConnection("jdbc:default:connection").
            createStatement().executeQuery("select * from t");
    }

and it succeeded, but only returned the result set created by
jdbc:default:connection. Is it intentional that we silently ignore the
result sets from other connections and closed result sets? Isn't it
more appropriate to raise an exception, or at least a warning?

Anyway, it seems like the test for the result set count has to be
moved from GenericPreparedStatement.execute() to
EmbedStatement.executeStatement(). Otherwise, we would have to import
impl.jdbc classes into impl.sql, which does not sound like a good
idea. According to the comment in GenericPreparedStatement, moving the
test could affect rollback, but I believe it is unaffected as long as
the test is performed inside the try block in ES.executeStatement(),
and before the commit logic. I also think moving the test from the sql
execution code to the jdbc code will make the code cleaner, since we
then get rid of the executeQuery/executeUpdate flags that currently
have to be passed to GPS.execute().

I'll add test cases for the other scenarios you mentioned as well.

> Client and embedded drivers differ on invoking a procedure that returns a single Dynamic
resultSet using CallableStatement.executeQuery()
> -----------------------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-501
>          URL: http://issues.apache.org/jira/browse/DERBY-501
>      Project: Derby
>         Type: Bug

>   Components: JDBC
>     Versions: 10.1.1.0, 10.0.2.1
>  Environment: All Platforms
>     Reporter: Satheesh Bandaram
>     Assignee: Knut Anders Hatlen
>  Attachments: Test.java, Test1.java, derby-501-v1.diff, derby-501-v1.stat
>
> It is possible to invoke a stored procedure that returns a single dynamic result using
CallableStatement.executeQuery using Derby Client. The embedded JDBC driver, however, throws
an exception like:
> Test starting ...url = jdbc:derby:tdb
> Exception in thread "main" ERROR X0Y78: Statement.executeQuery() cannot be called with
a statement that returns a row count.
>         at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:301)
>         at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:434)
>         at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1142)
>         at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1323)
>         at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:109)
>         at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(EmbedPreparedStatement.java:241)
>         at Test1.main(Test1.java:26)
> I think the embedded driver behavior is incorrect here, though I would double check that
the JDBC spec says. 
> To reproduce the problem,
> 1) Create a database called 'tdb' and a table called COMPANY as create table COMPANY(name
char(10));
> 2) Insert two rows as: insert into COMPANY values 'IBM', 'SUN';
> 3) register a procedure as:
> CREATE PROCEDURE GETALLCOMPANIES() PARAMETER STYLE JAVA LANGUAGE JAVA READS SQL DATA
DYNAMIC RESULT SETS 1 EXTERNAL NAME 'Test.getAllCompanies'
> 4) Set server classpath
> 5) Compile two attached java programs, Test and Test1
> 6) Execute 'java Test1 1' to run as a client program and 'java Test1 2' to run as an
embedded program.

-- 
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