[jira] Resolved: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-501?page=all ] Knut Anders Hatlen resolved DERBY-501: -- Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 414795. 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 Fix For: 10.2.0.0 Attachments: Test.java, Test1.java, derby-501-v1.diff, derby-501-v1.stat, derby-501-v2.diff, derby-501-v2.stat, derby-501-v3.diff, derby-501-v3.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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12416518 ] Knut Anders Hatlen commented on DERBY-137: -- I have (or more precisely, a test program of mine has) gone through all the DatabaseMetaData methods and compared them to the JDBC 4 spec. This is what I found: 1) Columns are missing from getColumns(), getTables() and getUDTs(). 2) Some columns that the spec says should be int are returned as SMALLINT, and some columns that should be short are returned as INTEGER. What's the best solution for 2? Changing all queries so that short maps to SMALLINT and int to INTEGER? Or should we accept other types as long as they could contain all values of the specified type (that is, allow short to be returned as INTEGER, but not int as SMALLINT)? Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Commented: (DERBY-1279) Bad column name in DatabaseMetaData.getColumns()
[ http://issues.apache.org/jira/browse/DERBY-1279?page=comments#action_12416715 ] Knut Anders Hatlen commented on DERBY-1279: --- As far as I can see, getColums() doesn't return any column named SCOPE_CATLOG or SCOPE_CATALOG (but it should return SCOPE_CATLOG according to the spec). getAttributes() returns SCOPE_CATALOG, but the spec spells 'catalog' correctly for that method. Bad column name in DatabaseMetaData.getColumns() Key: DERBY-1279 URL: http://issues.apache.org/jira/browse/DERBY-1279 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Fix For: 10.2.0.0 This method returns a column named SCOPE_CATLOG. Derby has corrected this typo to SCOPE_CATALOG. To conform to the spec, Derby should faithfully mis-spell this column name. -- 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
[jira] Commented: (DERBY-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution
[
http://issues.apache.org/jira/browse/DERBY-1183?page=comments#action_12416892 ]
Knut Anders Hatlen commented on DERBY-1183:
---
Dag, I see two failures in derbyall with this patch. From
lang/updatableResultSet.java I got a diff that was thousands of lines
long, but the relevant part seemed to be
* Diff file
derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/updatableResultSet.diff
*** Start: updatableResultSet jdk1.5.0_04 DerbyNetClient
derbynetmats:derbynetmats 2006-06-20 12:16:49 ***
[snip]
4778a137,138
FAIL: exception thrown:
ERROR XJ114: Invalid cursor name 'xxx-cursor-name-xxx'
Test Failed.
*** End: updatableResultSet jdk1.5.0_04 DerbyNetClient
derbynetmats:derbynetmats 2006-06-20 12:17:00 ***
jdbcapi/URCoveringIndexTest.junit also failed:
* Diff file
derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/jdbcapi/URCoveringIndexTest.diff
*** Start: URCoveringIndexTest jdk1.5.0_04 DerbyNetClient derbynetmats:jdbcapi
2006-06-20 12:28:52 ***
0 add
.E..E.
There were 2 errors:
1)
testUpdateUpdatedTupleScrollPostitioned(org.apache.derbyTesting.functionTests.tests.jdbcapi.URCoveringIndexTest)java.sql.SQLException:
Invalid cursor name 'SQL_CURLH000C2'.
Caused by: org.apache.derby.client.am.SqlException: Invalid cursor name
'SQL_CURLH000C2'.
... 17 more
2)
testUpdateUpdatedTupleFOPositioned(org.apache.derbyTesting.functionTests.tests.jdbcapi.URCoveringIndexTest)java.sql.SQLException:
Invalid cursor name 'SQL_CURLH000C3'.
Caused by: org.apache.derby.client.am.SqlException: Invalid cursor name
'SQL_CURLH000C3'.
... 17 more
FAILURES!!!
Tests run: 4, Failures: 0, Errors: 2
Test Failed.
*** End: URCoveringIndexTest jdk1.5.0_04 DerbyNetClient derbynetmats:jdbcapi
2006-06-20 12:29:00 ***
Could you please take a look at those failures? Thanks!
Client java.sql.ResultSet.getCursorName() does not return the correct cursor
name for Statements after the first execution
--
Key: DERBY-1183
URL: http://issues.apache.org/jira/browse/DERBY-1183
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.2.0.0
Reporter: Kathey Marsden
Assignee: Dag H. Wanvik
Fix For: 10.2.0.0
Attachments: derby-1183.diff, derby-1183.stat
For client, if the cursor name is set with java.sql.Statement.setCursorName()
the name set by the user only applies to the first execution. Subsequent
executions use the default cursor name. To reproduce run the progam below as
follows:
Djava -Dframework=DerbyNetClient GetCursorName
10.2.0.0 alpha
Apache Derby
Apache Derby Network Client JDBC Driver
rs.getCursorName():MyCursor
rs.getCursorName():SQL_CURLH000C2
With embedded it is ok:
Djava GetCursorName
10.2.0.0 alpha
Apache Derby
Apache Derby Embedded JDBC Driver
rs.getCursorName():MyCursor
rs.getCursorName():MyCursor
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.apache.derbyTesting.functionTests.util.TestUtil;
class GetCursorName
{
public static void main (String args [])throws Exception
{
testGetCursorName();
}
public static void testGetCursorName() throws SQLException
{
Connection conn =
TestUtil.getConnection(wombat,create=true);
Statement stmt = null;
ResultSet rs = null;
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
System.out.println(md.getDriverName());
stmt = conn.createStatement();
// Setting the cursor name works for one execution ok.
stmt.setCursorName(MyCursor);
rs = stmt.executeQuery(select count(*) from sys.systables);
System.out.println(rs.getCursorName(): + rs.getCursorName());
rs.close();
//Executing another query seems to clears the cursor name.
// getCursorName() will print the default cursor name SQLXXX.
rs = stmt.executeQuery(select count(*) from sys.systables);
System.out.println(rs.getCursorName(): + rs.getCursorName());
rs.close();
stmt.close();
conn.close();
}
}
I noticed this bug when coverting the checkDataSource test for client.
I will change that test to set the cursor name for each execution for client.
--
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
[jira] Created: (DERBY-1433) Client driver does not handle string literals containing where current of correctly
Client driver does not handle string literals containing where current of correctly - Key: DERBY-1433 URL: http://issues.apache.org/jira/browse/DERBY-1433 Project: Derby Type: Bug Components: Network Client, SQL Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Fix For: 10.2.0.0 If a string literal contains 'where current of something', the client driver tries to substitute 'something' with the corresponding cursor name on the server. This can lead to an exception being raised (no such cursor) or the string literal being modified. See attached repro. The bug is also present in JCC. -- 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
[jira] Updated: (DERBY-1433) Client driver does not handle string literals containing where current of correctly
[ http://issues.apache.org/jira/browse/DERBY-1433?page=all ] Knut Anders Hatlen updated DERBY-1433: -- Attachment: cursor.java Attached a repro for the bug (cursor.java). When the program is run, it is supposed to print Writing where current of in SQL is bad! but instead it prints Writing where current of SQL_CURLH000C1 SQL is bad! Client driver does not handle string literals containing where current of correctly - Key: DERBY-1433 URL: http://issues.apache.org/jira/browse/DERBY-1433 Project: Derby Type: Bug Components: Network Client, SQL Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: cursor.java If a string literal contains 'where current of something', the client driver tries to substitute 'something' with the corresponding cursor name on the server. This can lead to an exception being raised (no such cursor) or the string literal being modified. See attached repro. The bug is also present in JCC. -- 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ] Knut Anders Hatlen updated DERBY-137: - Attachment: derby-137-v1.diff derby-137-v1.stat The attached patch changes the data types and adds missing columns so that the result sets returned from DatabaseMetaData methods match the latest revision of the JDBC 4.0 spec. Derbyall ran cleanly on Sun JVM 1.5.0/Solaris 10 x64. Summary of the changes: DatabaseMetaData: - getProcedureColumns: modified VTI to return an int instead of a short for the DATA_TYPE column - getTables: new columns: TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, REF_GENERATION (all null since Derby doesn't support typed tables) - getColumns: DATA_TYPE changed from SMALLINT to INTEGER. New columns: SCOPE_CATLOG, SCOPE_SCHEMA, SCOPE_TABLE, SOURCE_DATATYPE (all null since Derby doesn't support the REF or DISTINCT data types) - getVersionColumns: SCOPE, DECIMAL_DIGITS and PSEUDO_COLUMN changed from INTEGER to SMALLINT - getPrimaryKeys: KEY_SEQ changed from INTEGER to SMALLINT - getTypeInfo: DATA_TYPE, NULLABLE, SEARCHABLE, MINIMUM_SCALE and MAXIMUM_SCALE changed from SMALLINT to INTEGER. - getIndexInfo: ORDINAL_POSITION changed from INTEGER to SMALLINT - getBestRowIdentifier: DATA_TYPE changed from SMALLINT to INTEGER - getUDTs: new columm: BASE_TYPE (null since Derby doesn't support the DISTINCT type or SELF_REFERENCING_COLUMN) ODBCMetadataGenerator: - cast DATA_TYPE columns to SMALLINT (as defined by ODBC) Tests: - updated master files for metadata, odbc_metadata, bestrowidentifier, declareGlobalTempTableJava and Upgrade_10_1_10_2 (new columns and modified data types) - odbc_metadata.java: added information about nullability for some of the new columns to avoid ArrayIndexOutOfBoundsException Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Attachments: derby-137-v1.diff, derby-137-v1.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ] Knut Anders Hatlen updated DERBY-137: - Derby Info: [Patch Available] Patch is available and ready for review. Thanks! Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Attachments: derby-137-v1.diff, derby-137-v1.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Commented: (DERBY-1314) Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1314?page=comments#action_12417104 ] Knut Anders Hatlen commented on DERBY-1314: --- Does anyone have comments to the patch? If not, I plan to commit in a couple of days. Differences between client and embedded when invoking stored procedures using Statement.executeUpdate() --- Key: DERBY-1314 URL: http://issues.apache.org/jira/browse/DERBY-1314 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: derby-1314-v1.diff, derby-1314-v1.stat When invoking a stored procedure using Statement.executeUpdate(), the client driver and the embedded driver behave differently. If the stored procedure does not return any result set, the embedded driver returns 0, whereas the client returns -1. If the stored procedure returns one or more result sets, the embedded driver returns -1, whereas the client fails with an exception. -- 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
[jira] Assigned: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen reassigned DERBY-1393: - Assign To: Knut Anders Hatlen PreparedStatement.setObject(Object,int,int) should throw for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Resolved: (DERBY-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution
[ http://issues.apache.org/jira/browse/DERBY-1183?page=all ]
Knut Anders Hatlen resolved DERBY-1183:
---
Resolution: Fixed
Dag, I made two changes to your last patch before committing.
1) A couple of println statements had been added to SectionManager.java (all
commented out). I removed those.
2) One of the work-arounds for DERBY-1036 in checkDataSource.java was only
partially removed:
Your patch:
- //DERBY-1036 - need a new name
- //s.setCursorName(StokeNewington);
+ s.setCursorName(StokeNewington);
s.setCursorName(districtInLondon);
Committed change:
- //DERBY-1036 - need a new name
- //s.setCursorName(StokeNewington);
- s.setCursorName(districtInLondon);
+ s.setCursorName(StokeNewington);
The patch was committed into trunk with revision 416661.
Client java.sql.ResultSet.getCursorName() does not return the correct cursor
name for Statements after the first execution
--
Key: DERBY-1183
URL: http://issues.apache.org/jira/browse/DERBY-1183
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.2.0.0
Reporter: Kathey Marsden
Assignee: Dag H. Wanvik
Fix For: 10.2.0.0
Attachments: derby-1183-2.diff, derby-1183-2.stat, derby-1183.diff,
derby-1183.stat
For client, if the cursor name is set with java.sql.Statement.setCursorName()
the name set by the user only applies to the first execution. Subsequent
executions use the default cursor name. To reproduce run the progam below as
follows:
Djava -Dframework=DerbyNetClient GetCursorName
10.2.0.0 alpha
Apache Derby
Apache Derby Network Client JDBC Driver
rs.getCursorName():MyCursor
rs.getCursorName():SQL_CURLH000C2
With embedded it is ok:
Djava GetCursorName
10.2.0.0 alpha
Apache Derby
Apache Derby Embedded JDBC Driver
rs.getCursorName():MyCursor
rs.getCursorName():MyCursor
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import org.apache.derbyTesting.functionTests.util.TestUtil;
class GetCursorName
{
public static void main (String args [])throws Exception
{
testGetCursorName();
}
public static void testGetCursorName() throws SQLException
{
Connection conn =
TestUtil.getConnection(wombat,create=true);
Statement stmt = null;
ResultSet rs = null;
DatabaseMetaData md = conn.getMetaData() ;
System.out.println(md.getDatabaseProductVersion());
System.out.println(md.getDatabaseProductName());
System.out.println(md.getDriverName());
stmt = conn.createStatement();
// Setting the cursor name works for one execution ok.
stmt.setCursorName(MyCursor);
rs = stmt.executeQuery(select count(*) from sys.systables);
System.out.println(rs.getCursorName(): + rs.getCursorName());
rs.close();
//Executing another query seems to clears the cursor name.
// getCursorName() will print the default cursor name SQLXXX.
rs = stmt.executeQuery(select count(*) from sys.systables);
System.out.println(rs.getCursorName(): + rs.getCursorName());
rs.close();
stmt.close();
conn.close();
}
}
I noticed this bug when coverting the checkDataSource test for client.
I will change that test to set the cursor name for each execution for client.
--
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
[jira] Resolved: (DERBY-1036) Embedded and client differ with regard to Statement.setCursor Name. client will disallow duplicate cursor names. Embedded will allow it.
[ http://issues.apache.org/jira/browse/DERBY-1036?page=all ] Knut Anders Hatlen resolved DERBY-1036: --- Fix Version: 10.2.0.0 Resolution: Fixed Dag's patch for DERBY-1183 and this issue committed into trunk with revision 416661. Embedded and client differ with regard to Statement.setCursor Name. client will disallow duplicate cursor names. Embedded will allow it. - Key: DERBY-1036 URL: http://issues.apache.org/jira/browse/DERBY-1036 Project: Derby Type: Sub-task Components: Network Client, JDBC Versions: 10.1.3.0, 10.1.2.3, 10.2.0.0 Reporter: Kathey Marsden Assignee: Dag H. Wanvik Priority: Minor Fix For: 10.2.0.0 In looking at the checkDataSource test for DERBY-435, I hit an issue that the test fails with an exception for duplicate cursor name because it sets the cursor name for two statements to the same thing. Embedded seems to allow this, but it seems to me that client might be right here. How could embedded differentiate the two for positioned updates? There is risk to existing applications if embedded is changed to throw the error that should be considered if we decide we need to change the embedded behaviour. Below are some details from checkDataSource where I hit this. I will change the names for now as it does not seem relevant to what is being tested. PreparedStatement psruState = createFloatStatementForStateChecking(cs1, select i from ru where i = ?); CallableStatement csruState = createFloatCallForStateChecking(cs1, CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?,?)); Both of these methods set the cursor name to the same thing: s.setCursorName(StokeNewington); For embedded it succeeds for client it throws the exception. java.sql.SQLException: Duplicate cursor names are not allowed. at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.client.am.Statement.setCursorName(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.createFloatStatementForStateChecking(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(Unknown Source) at org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(Unknown Source) -- 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
[jira] Closed: (DERBY-1314) Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1314?page=all ] Knut Anders Hatlen closed DERBY-1314: - Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 416696. Differences between client and embedded when invoking stored procedures using Statement.executeUpdate() --- Key: DERBY-1314 URL: http://issues.apache.org/jira/browse/DERBY-1314 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: derby-1314-v1.diff, derby-1314-v1.stat When invoking a stored procedure using Statement.executeUpdate(), the client driver and the embedded driver behave differently. If the stored procedure does not return any result set, the embedded driver returns 0, whereas the client returns -1. If the stored procedure returns one or more result sets, the embedded driver returns -1, whereas the client fails with an exception. -- 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
[jira] Assigned: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen reassigned DERBY-1364: - Assign To: Knut Anders Hatlen Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Commented: (DERBY-1445) Add new streaming overloads and modify some existing ones.
[
http://issues.apache.org/jira/browse/DERBY-1445?page=comments#action_12417495 ]
Knut Anders Hatlen commented on DERBY-1445:
---
Hi Narayanan,
It seems like your editor has eight character tabs, so your
indentation doesn't always match the surrounding code. For instance,
the javadocs for EmbedResultSet.updateAsciiStream, updateBinaryStream
and updateCharacterStream are indented with four characters too much.
I also notice that several places the indentation is a mix of tabs and
spaces. For instance, in EmbedPreparedStatement you have
+public final void setCharacterStream(int parameterIndex,
+ java.io.Reader reader,
+ int length) throws SQLException {
+setCharacterStream(parameterIndex,reader,(long)length);
+}
First line is indented with spaces only.
Second line with spaces followed by tabs followed by spaces.
Third line with tabs followed by spaces.
Fourth line and fifth line are indented with spaces only.
Please check your tab setting (four characters) and try to keep the
indentation consistent (at least try to avoid mixing tabs and spaces
on the same line). Thanks!
Add new streaming overloads and modify some existing ones.
---
Key: DERBY-1445
URL: http://issues.apache.org/jira/browse/DERBY-1445
Project: Derby
Type: New Feature
Components: JDBC
Reporter: V.Narayanan
Assignee: V.Narayanan
Attachments: JDBC40_long_length_overloads.diff,
JDBC40_long_length_overloads.stat
The task involves Adding and modifying the following methods
add PreparedStatement.setAsciiStream (int columnIndex, InputStream x,
long length)
add PreparedStatement.setBinaryStream (int columnIndex, InputStream x,
long length
add PreparedStatement.setCharacterStream (int columnIndex, Reader x,
long length)
add CallableStatement.setAsciiStream (String columnName, InputStream x,
long length)
add CallableStatement.setBinaryStream (String columnName, InputStream
x, long length)
add CallableStatement.setCharacterStream (String columnName, Reader x,
long length)
add ResultSet.updateAsciiStream (int columnIndex, InputStream x, long
length)
add ResultSet.updateBinaryStream (int columnIndex, InputStream x, long
length)
add ResultSet.updateCharacterStream (int columnIndex, Reader x, long
length)
add ResultSet.updateAsciiStream (String columnName, InputStream x, long
length)
add ResultSet.updateBinaryStream (String columnName, InputStream x,
long length)
add ResultSet.updateCharacterStream (String columnName, Reader x, long
length)
add ResultSet.updateBlob (int columnIndex, InputStream x, long length)
add ResultSet.updateBlob (String columnName, InputStream x, long length)
add ResultSet.updateClob (int columnIndex, Reader x, long length)
add ResultSet.updateClob (String columnName, Reader x, long length)
add ResultSet.updateNClob (int columnIndex, Reader x, long length)
add ResultSet.updateNClob (String columnName, Reader x, long length)
modify ResultSet.updateNCharacterStream(int columnIndex, Reader x, int
length) to ResultSet.updateNCharacterStream(int columnIndex, Reader x, long
length)
modify ResultSet.updateNCharacterStream(String columnName, Reader x,
int length) to ResultSet.updateNCharacterStream(String columnName,
Reader x, long length)
--
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
[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417497 ] Knut Anders Hatlen commented on DERBY-1275: --- Hi Kathey, I think your approach sounds reasonable. It is definitely good to have some simple way (documented or undocumented) to enable client-side tracing. By not documenting it, we don't commit to support it in case we find a better way in the future. However, I think it's a good idea that we maintain a list of such undocumented features somewhere. Otherwise, I fear that they will be forgotten and just make the code less maintainable. What about creating a wiki page with undocumented properties/features (clearly labelled as unsupported, of course)? Provide a way to enable client tracing without changing the application --- Key: DERBY-1275 URL: http://issues.apache.org/jira/browse/DERBY-1275 Project: Derby Type: Improvement Components: Network Client Versions: 10.2.0.0, 10.1.2.3 Reporter: Kathey Marsden Priority: Minor Currently the client tracing can be enabled by setting attributes on the client url, setXXX methods on the DataSource or calling DriverManager.setLogWriter(), but it often cannot be enabled in a deployed client application because all of these API's require modification of the application or its configuration files. It would be good to have a global way to turn on client tracing. A system property pointing to a property file is one possibility but probably not ideal because of the impact in class loader contexts.I am not sure what the other possiblities are, -- 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
[jira] Commented: (DERBY-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=comments#action_12417553 ] Knut Anders Hatlen commented on DERBY-955: -- I plan to review and commit Olav's patch. If someone has comments or is planning to review, please let me know. Thanks! Get derbyall on jdk1.6 -- Key: DERBY-955 URL: http://issues.apache.org/jira/browse/DERBY-955 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Anurag Shekhar Fix For: 10.2.0.0 Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- 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
[jira] Updated: (DERBY-1425) testProtocol hangs with 10.1 client talking to 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1425?page=all ] Knut Anders Hatlen updated DERBY-1425: -- Attachment: ddmreader_initialize.diff ddmreader_initialize.diff contains the changes to DDMReader which made the hang go away. I have not had time to check whether these changes have unwanted consequences. Use at your own risk! :) testProtocol hangs with 10.1 client talking to 10.2 server -- Key: DERBY-1425 URL: http://issues.apache.org/jira/browse/DERBY-1425 Project: Derby Type: Bug Components: Network Server, Network Client Versions: 10.2.0.0 Reporter: Bryan Pendleton Priority: Minor Attachments: ddmreader_initialize.diff I was trying to verify that the changes in DERBY-920 hadn't introduced any new compatibility problems (they shouldn't, because we were changing an internal class, but I wanted to make sure). So I was trying to follow some old tips about how to run tests with an old client against a new server, as documented in: http://wiki.apache.org/db-derby/TestingOldClientNewServer However, when I did this, the test testProtocol did not terminate. -- 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
[jira] Commented: (DERBY-955) Get derbyall on jdk1.6
[ http://issues.apache.org/jira/browse/DERBY-955?page=comments#action_12417592 ] Knut Anders Hatlen commented on DERBY-955: -- The patch looks clean and simple. Ran derbyall on jdk15 with one error (runtimeinfo.java which fails more or less all the time on my machine) and on jdk16 with ten errors (DerbyNetAutoStart with the client driver and JCC + four errors in the jdbc40 suite (both client and embedded) caused by new overloads that are not implemented yet). Committed bug955_derbyall.diff into trunk with revision 416889. Get derbyall on jdk1.6 -- Key: DERBY-955 URL: http://issues.apache.org/jira/browse/DERBY-955 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Anurag Shekhar Fix For: 10.2.0.0 Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff This bug is a placeholder for patches which enable derbyall to run on jdk1.6. -- 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
[jira] Updated: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen updated DERBY-1364: -- Attachment: derby-1364-v1.diff derby-1364-v1.stat Attached a patch (derby-1364-v1.diff) which attempts to fix this issue. Description of the patch: 1. Checking of the number of result sets returned was moved from executeUpdate/executeQuery to a point in flowExecute where the transaction has not been auto-committed (otherwise, the transaction would already be committed when the exception was raised). 2. If the number of result sets does not match the execute type and auto-commit is enabled, the transaction is rolled back (otherwise, the transaction would be committed when the Statement was closed or re-executed). 3. All execute* methods in CallableStatement were removed since they have become identical to the methods in PreparedStatement. (Or almost identical. The methods in CallableStatement did not call checkStatementValidity() on errors, but that's probably a bug.) 4. SQL state for error message in executeQuery() was changed to match embedded (XJ201/XJ205 - X0Y78). Updated English and Portuguese messages to use the new SQL state (no other translations existed for XJ201 and XJ205). 5. Added more rollback tests to jdbcapi/ProcedureTest.junit and enabled all test cases for DerbyNetClient. I have run derbyall with no failures except runtimeinfo.java which fails all the time. The patch is ready for review. Thanks! Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1364-v1.diff, derby-1364-v1.stat When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Updated: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen updated DERBY-1364: -- Derby Info: [Patch Available] Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1364-v1.diff, derby-1364-v1.stat When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Created: (DERBY-1455) Intermittent failure in derbynet/runtimeinfo.java
Intermittent failure in derbynet/runtimeinfo.java - Key: DERBY-1455 URL: http://issues.apache.org/jira/browse/DERBY-1455 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assigned to: Knut Anders Hatlen Priority: Minor I often see failures of this type in derbynet/runtimeinfo.java: * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/runtimeinfo.diff *** Start: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:43 *** 57a58,66 Session # :4 Database :wombat;create=true User :APP # Statements:2 Prepared Statement Information: Stmt ID SQLText - --- SYSLH0002 VALUES(2) SYSLH0001 SELECT count(*) from sys.systables 61 del # Active Sessions : 1 61a70 # Active Sessions : 2 Test Failed. *** End: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:51 *** It doesn't seem to happen very frequently in Ole's nightly testing, but it has occurred there too: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/386483-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/354827-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/355169-derbynetmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/321161-derbynetclientmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/370878-derbyall_diff.txt -- 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
[jira] Updated: (DERBY-1455) Intermittent failure in derbynet/runtimeinfo.java
[ http://issues.apache.org/jira/browse/DERBY-1455?page=all ] Knut Anders Hatlen updated DERBY-1455: -- Attachment: derby-1455.diff derby-1455.stat Attached a patch which seems to fix the problem. I ran the test 421 times with the jar files from the 10.2.0.3 snapshot, and it failed 337 times (80% of the time). With the patch applied, I ran the test 814 times without any failures. The problem occurs when the test has opened four connections, closes three of them and runs getRuntimeInfo() on the server. The test expects that there is one active session on the server, but in some cases, the network server has not had enough time to clean up after the closed connections, and more sessions are listed as active. The patch solves this timing issue by invoking Thread.sleep(1000) before calling getRuntimeInfo(). Intermittent failure in derbynet/runtimeinfo.java - Key: DERBY-1455 URL: http://issues.apache.org/jira/browse/DERBY-1455 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-1455.diff, derby-1455.stat I often see failures of this type in derbynet/runtimeinfo.java: * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/runtimeinfo.diff *** Start: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:43 *** 57a58,66 Session # :4 Database :wombat;create=true User :APP # Statements:2 Prepared Statement Information: Stmt ID SQLText - --- SYSLH0002 VALUES(2) SYSLH0001 SELECT count(*) from sys.systables 61 del # Active Sessions : 1 61a70 # Active Sessions : 2 Test Failed. *** End: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:51 *** It doesn't seem to happen very frequently in Ole's nightly testing, but it has occurred there too: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/386483-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/354827-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/355169-derbynetmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/321161-derbynetclientmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/370878-derbyall_diff.txt -- 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
[jira] Updated: (DERBY-1455) Intermittent failure in derbynet/runtimeinfo.java
[ http://issues.apache.org/jira/browse/DERBY-1455?page=all ] Knut Anders Hatlen updated DERBY-1455: -- Derby Info: [Patch Available] Intermittent failure in derbynet/runtimeinfo.java - Key: DERBY-1455 URL: http://issues.apache.org/jira/browse/DERBY-1455 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-1455.diff, derby-1455.stat I often see failures of this type in derbynet/runtimeinfo.java: * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/runtimeinfo.diff *** Start: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:43 *** 57a58,66 Session # :4 Database :wombat;create=true User :APP # Statements:2 Prepared Statement Information: Stmt ID SQLText - --- SYSLH0002 VALUES(2) SYSLH0001 SELECT count(*) from sys.systables 61 del # Active Sessions : 1 61a70 # Active Sessions : 2 Test Failed. *** End: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:51 *** It doesn't seem to happen very frequently in Ole's nightly testing, but it has occurred there too: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/386483-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/354827-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/355169-derbynetmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/321161-derbynetclientmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/370878-derbyall_diff.txt -- 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
[jira] Commented: (DERBY-1425) testProtocol hangs with 10.1 client talking to 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1425?page=comments#action_12417731 ] Knut Anders Hatlen commented on DERBY-1425: --- Yes, the test still fails, but I don't think a separate issue is needed since the test should fail in a mixed environment. It does not test whether the client works, but whether the server responds exactly the way a 10.1 server would. One might even argue that derbynetmats/derbynetclientmats is not the correct suite for this test since it neither uses the client driver nor JCC. testProtocol hangs with 10.1 client talking to 10.2 server -- Key: DERBY-1425 URL: http://issues.apache.org/jira/browse/DERBY-1425 Project: Derby Type: Bug Components: Network Server, Network Client Versions: 10.2.0.0 Reporter: Bryan Pendleton Priority: Minor Attachments: ddmreader_initialize.diff I was trying to verify that the changes in DERBY-920 hadn't introduced any new compatibility problems (they shouldn't, because we were changing an internal class, but I wanted to make sure). So I was trying to follow some old tips about how to run tests with an old client against a new server, as documented in: http://wiki.apache.org/db-derby/TestingOldClientNewServer However, when I did this, the test testProtocol did not terminate. -- 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
[jira] Closed: (DERBY-1455) Intermittent failure in derbynet/runtimeinfo.java
[ http://issues.apache.org/jira/browse/DERBY-1455?page=all ] Knut Anders Hatlen closed DERBY-1455: - Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 417131. Intermittent failure in derbynet/runtimeinfo.java - Key: DERBY-1455 URL: http://issues.apache.org/jira/browse/DERBY-1455 Project: Derby Type: Bug Components: Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1455.diff, derby-1455.stat I often see failures of this type in derbynet/runtimeinfo.java: * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/runtimeinfo.diff *** Start: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:43 *** 57a58,66 Session # :4 Database :wombat;create=true User :APP # Statements:2 Prepared Statement Information: Stmt ID SQLText - --- SYSLH0002 VALUES(2) SYSLH0001 SELECT count(*) from sys.systables 61 del # Active Sessions : 1 61a70 # Active Sessions : 2 Test Failed. *** End: runtimeinfo jdk1.5.0_04 DerbyNetClient derbynetmats:derbynetmats 2006-01-20 23:19:51 *** It doesn't seem to happen very frequently in Ole's nightly testing, but it has occurred there too: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/386483-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/354827-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.14-1.1644_FC4_i686-i686/355169-derbynetmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/321161-derbynetclientmats_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/370878-derbyall_diff.txt -- 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
[jira] Commented: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=comments#action_12417738 ] Knut Anders Hatlen commented on DERBY-137: -- I plan to commit this patch tomorrow. If someone is planning to review, please let me know and I'll hold the commit. Thanks! Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Attachments: derby-137-v1.diff, derby-137-v1.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12417760 ] Knut Anders Hatlen commented on DERBY-1393: --- Does Derby support JAVA_OBJECT? Types.JAVA_OBJECT is used in the code, but I have not been able to find out how an application could use this data type. I believe that the type id is for user-defined types, which are not supported by Derby (at least not exposed to the applications). If my assumptions are correct, the full list of types that should throw SQLFeatureNotSupportedException is: ARRAY, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML and STRUCT. PreparedStatement.setObject(Object,int,int) should throw for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Commented: (DERBY-1450) jdbcapi/parameterMetaDataJdbc30.java fails with 10.1 client and 10.2 server
[ http://issues.apache.org/jira/browse/DERBY-1450?page=comments#action_12417800 ] Knut Anders Hatlen commented on DERBY-1450: --- This is caused by a test case for DERBY-44 which is supposed to test a) that Derby understands the LIKE/ESCAPE syntax b) that an empty escape string causes SQLException with SQL state 22019, not IndexOutOfBoundsException However, since the test only executes the statement and doesn't fetch data, b is never triggered in 10.1 (neither with the embedded driver nor with the client driver). In 10.2, the client driver pre-fetches data (DERBY-822) hence b is triggered. In the 10.2 code line, the test is also updated so that b is triggered regardless of pre-fetching (the exception is also raised by the embedded driver). jdbcapi/parameterMetaDataJdbc30.java fails with 10.1 client and 10.2 server --- Key: DERBY-1450 URL: http://issues.apache.org/jira/browse/DERBY-1450 Project: Derby Type: Test Versions: 10.2.0.0, 10.1.3.0 Environment: derbyclient.jar and derbyTesting.jar from 10.1 all other jars from 10.2 Reporter: Deepa Remesh Test fails with following exception: SQLSTATE(22019):org.apache.derby.client.am.SqlException: Invalid escape sequence, ''. The escape string must be exactly one character. It cannot be a null or more than one character. at org.apache.derby.client.am.Statement.completeSqlca(Statement.java:1371) at org.apache.derby.client.net.NetStatementReply.parseOpenQueryError(NetStatementReply.java:605) at org.apache.derby.client.net.NetStatementReply.parseOPNQRYreply(NetStatementReply.java:229) at org.apache.derby.client.net.NetStatementReply.readOpenQuery(NetStatementReply.java:56) at org.apache.derby.client.net.StatementReply.readOpenQuery(StatementReply.java:49) at org.apache.derby.client.net.NetStatement.readOpenQuery_(NetStatement.java:151) at org.apache.derby.client.am.Statement.readOpenQuery(Statement.java:1038) at org.apache.derby.client.am.PreparedStatement.flowExecute(PreparedStatement.java:1396) at org.apache.derby.client.am.PreparedStatement.executeX(PreparedStatement.java:893) at org.apache.derby.client.am.PreparedStatement.execute(PreparedStatement.java:884) at org.apache.derbyTesting.functionTests.tests.jdbcapi.parameterMetaDataJdbc30.main(parameterMetaDataJdbc30.java:146) -- 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
[jira] Updated: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ] Knut Anders Hatlen updated DERBY-137: - Attachment: derby-137-v2.diff derby-137-v2.stat Thank you very much for reviewing, A B! You are right; NULLABLE, SEARCHABLE, MINIMUM_SCALE and MAXIMUM_SCALE are still listed as short in the javadoc. I meant to say that they had been changed from INT to SMALLINT in the queries (which is what the patch actually did). This means the casts are not necessary for these columns either in the ODBC queries. I don't think changing the ODBC rewriting should affect soft upgrade in any way. Derby will read the new queries directly from metadata.properties, and they don't require any 10.2 features that are not available in soft-upgrade mode. I have attached a new patch (v2) which removes the unnecessary casts to SMALLINT generated by the ODBC generator. With that change, getPrimaryKeys() is ODBC compliant, so SystemProcedures.SQLPRIMARYKEYS() now uses the JDBC query for ODBC requests. Derbyall (including the upgrade test) still passes. Do you think these changes are OK? Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Attachments: derby-137-v1.diff, derby-137-v1.stat, derby-137-v2.diff, derby-137-v2.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Commented: (DERBY-1445) Add new streaming overloads and modify some existing ones.
[ http://issues.apache.org/jira/browse/DERBY-1445?page=comments#action_12418015 ] Knut Anders Hatlen commented on DERBY-1445: --- Thanks Narayanan and Kristian! I will look into committing the patch. Add new streaming overloads and modify some existing ones. --- Key: DERBY-1445 URL: http://issues.apache.org/jira/browse/DERBY-1445 Project: Derby Type: New Feature Components: JDBC Reporter: V.Narayanan Assignee: V.Narayanan Attachments: JDBC40_long_length_overloads.diff, JDBC40_long_length_overloads.stat, JDBC40_long_length_overloads_ver2.diff, JDBC40_long_length_overloads_ver2.stat, JDBC40_long_length_overloads_ver3.diff, JDBC40_long_length_overloads_ver3.stat The task involves Adding and modifying the following methods, which were recently added by the JDBC4 expert group and which appeared in Mustang build 86: add PreparedStatement.setAsciiStream (int columnIndex, InputStream x, long length) add PreparedStatement.setBinaryStream (int columnIndex, InputStream x, long length add PreparedStatement.setCharacterStream (int columnIndex, Reader x, long length) add CallableStatement.setAsciiStream (String columnName, InputStream x, long length) add CallableStatement.setBinaryStream (String columnName, InputStream x, long length) add CallableStatement.setCharacterStream (String columnName, Reader x, long length) add ResultSet.updateAsciiStream (int columnIndex, InputStream x, long length) add ResultSet.updateBinaryStream (int columnIndex, InputStream x, long length) add ResultSet.updateCharacterStream (int columnIndex, Reader x, long length) add ResultSet.updateAsciiStream (String columnName, InputStream x, long length) add ResultSet.updateBinaryStream (String columnName, InputStream x, long length) add ResultSet.updateCharacterStream (String columnName, Reader x, long length) add ResultSet.updateBlob (int columnIndex, InputStream x, long length) add ResultSet.updateBlob (String columnName, InputStream x, long length) add ResultSet.updateClob (int columnIndex, Reader x, long length) add ResultSet.updateClob (String columnName, Reader x, long length) add ResultSet.updateNClob (int columnIndex, Reader x, long length) add ResultSet.updateNClob (String columnName, Reader x, long length) modify ResultSet.updateNCharacterStream(int columnIndex, Reader x, int length) to ResultSet.updateNCharacterStream(int columnIndex, Reader x, long length) modify ResultSet.updateNCharacterStream(String columnName, Reader x, int length) to ResultSet.updateNCharacterStream(String columnName, Reader x, long length) -- 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
[jira] Resolved: (DERBY-137) Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required.
[ http://issues.apache.org/jira/browse/DERBY-137?page=all ] Knut Anders Hatlen resolved DERBY-137: -- Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks again for the quick review, A B! Committed v2 patch into trunk with revision 417497. Derby metadata always returns JDBC 2 result sets, even when JDBC 3 result sets are required. Key: DERBY-137 URL: http://issues.apache.org/jira/browse/DERBY-137 Project: Derby Type: Bug Components: JDBC Reporter: A B Assignee: Knut Anders Hatlen Priority: Critical Fix For: 10.2.0.0 Attachments: derby-137-v1.diff, derby-137-v1.stat, derby-137-v2.diff, derby-137-v2.stat BACKGROUND: Derby's implementation of the JDBC class java.sql.DatabaseMetaData returns result sets that are defined by the SQL queries in impl/jdbc/metadata.properties. PROBLEM: The current queries in the metadata.properties file are for JDBC 2 only. The queries do NOT account for the result sets as defined by JDBC 3, and thus even when JDBC 3 result sets should be returned, a user will get metadata correlating to the JDBC 2 standard. Just for reference, here are a couple of examples of changes that have been made from JDBC 2 to JDBC 3: 1) getColumns(): JDBC 2 specifies 18 columns, JDBC 3 specifies 22 (the four extra columns are SCOPE_CATALOG, SCOPE_SCHEMA, SCOPE_TABLE, and SOURCE_DATA_TYPE). 2) getTables(): JDBC 2 specifics 5 columns, JDBC 3 specifies 10 (the five extra columns are TYPE_CAT, TYPE_SCHEM, TYPE_NAME, SELF_REFERENCING_COL_NAME, and REF_GENERATION). 3) getProcedureColumns(): JDBC 2 specifies that DATA_TYPE is a short; JDBC 3 specifies that DATA_TYPE is an int. NOTES: JDBC 3 needs to be backward compatible with JDBC 2, so it should be okay to just modify metadata.properties to return JDBC 3 result sets... -- 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
[jira] Updated: (DERBY-1445) Add new streaming overloads and modify some existing ones.
[ http://issues.apache.org/jira/browse/DERBY-1445?page=all ]
Knut Anders Hatlen updated DERBY-1445:
--
Attachment: ver3-washed.diff
The ver2 and ver3 patches reformatted large portions of otherwise
unmodified code. This makes it rather difficult to see what has been
changed by the patch, and it increases the probability of conflicts
with others working in this area of the code. Also, there were still
some methods that were indented more than the surrounding code. I took
the liberty of washing the formatting changes and incorrect
indentation out of the patch before reviewing and committing it.
The washed patch (based on ver3) is attached as ver3-washed.diff. It
was committed into trunk with revision 417548. With this commit, the
four jdbc40 tests that have been failing the last weeks now run
cleanly. Thank you Narayanan!
I still see two issues with the patch, and it would be great if you
could address them in a follow-up patch.
1) CallableStatementTest: testSetCharacterStream, testSetAsciiStream
and testSetBinaryStream only fail if an exception is thrown that is
not SQLFeatureNotSupportedException. They should also fail if no
exception is thrown.
2) (This one is a minor issue which you can ignore if you want.) I
agree with Kristian's earlier review comment that there is no need
to catch exceptions in JUnit tests when you don't take corrective
actions. That is, instead of writing
try {
doSomething();
} catch (SomeKindOfException e) {
fail(Failed + e.getMessage());
}
you could just declare the test method as throws Exception and
skip try/catch/fail. It is simpler, and you also lose less
information in the case of a failure (you preserve the stack trace,
and possibly caused by...). The try/catch/fail pattern is used in
PreparedStatementTest (testSetCharacterStream, testSetAsciiStream,
testSetBinaryStream) and ResultSetTest (testUpdateBinaryStream,
testUpdateAsciiStream, testUpdateCharacterStream,
testUpdateBinaryStreamStringParameterName,
testUpdateAsciiStreamStringParameterName,
testUpdateCharacterStreamStringParameterName, embeddedUpdateClob,
embeddedUpdateClobStringParameterName, embeddedUpdateBlob,
embeddedUpdateBlobStringParameterName).
Thanks!
Add new streaming overloads and modify some existing ones.
---
Key: DERBY-1445
URL: http://issues.apache.org/jira/browse/DERBY-1445
Project: Derby
Type: New Feature
Components: JDBC
Reporter: V.Narayanan
Assignee: V.Narayanan
Attachments: JDBC40_long_length_overloads.diff,
JDBC40_long_length_overloads.stat, JDBC40_long_length_overloads_ver2.diff,
JDBC40_long_length_overloads_ver2.stat,
JDBC40_long_length_overloads_ver3.diff,
JDBC40_long_length_overloads_ver3.stat, ver3-washed.diff
The task involves Adding and modifying the following methods, which were
recently added by the JDBC4 expert group and which appeared in Mustang build
86:
add PreparedStatement.setAsciiStream (int columnIndex, InputStream x,
long length)
add PreparedStatement.setBinaryStream (int columnIndex, InputStream x,
long length
add PreparedStatement.setCharacterStream (int columnIndex, Reader x,
long length)
add CallableStatement.setAsciiStream (String columnName, InputStream x,
long length)
add CallableStatement.setBinaryStream (String columnName, InputStream
x, long length)
add CallableStatement.setCharacterStream (String columnName, Reader x,
long length)
add ResultSet.updateAsciiStream (int columnIndex, InputStream x, long
length)
add ResultSet.updateBinaryStream (int columnIndex, InputStream x, long
length)
add ResultSet.updateCharacterStream (int columnIndex, Reader x, long
length)
add ResultSet.updateAsciiStream (String columnName, InputStream x, long
length)
add ResultSet.updateBinaryStream (String columnName, InputStream x,
long length)
add ResultSet.updateCharacterStream (String columnName, Reader x, long
length)
add ResultSet.updateBlob (int columnIndex, InputStream x, long length)
add ResultSet.updateBlob (String columnName, InputStream x, long length)
add ResultSet.updateClob (int columnIndex, Reader x, long length)
add ResultSet.updateClob (String columnName, Reader x, long length)
add ResultSet.updateNClob (int columnIndex, Reader x, long length)
add ResultSet.updateNClob (String columnName, Reader x, long length)
modify ResultSet.updateNCharacterStream(int columnIndex, Reader x, int
length) to ResultSet.updateNCharacterStream(int columnIndex, Reader x, long
length)
modify ResultSet.updateNCharacterStream(String columnName, Reader x,
int length) to ResultSet.updateNCharacterStream(String columnName,
Reader x, long length)
--
This message is automatically
[jira] Resolved: (DERBY-1445) Add new streaming overloads and modify some existing ones.
[ http://issues.apache.org/jira/browse/DERBY-1445?page=all ] Knut Anders Hatlen resolved DERBY-1445: --- Fix Version: 10.2.0.0 Resolution: Fixed Thanks! Committed the follow-up patch into trunk with revision 417705. Add new streaming overloads and modify some existing ones. --- Key: DERBY-1445 URL: http://issues.apache.org/jira/browse/DERBY-1445 Project: Derby Type: New Feature Components: JDBC Reporter: V.Narayanan Assignee: V.Narayanan Fix For: 10.2.0.0 Attachments: JDBC40_long_length_overloads.diff, JDBC40_long_length_overloads.stat, JDBC40_long_length_overloads_ver2.diff, JDBC40_long_length_overloads_ver2.stat, JDBC40_long_length_overloads_ver3.diff, JDBC40_long_length_overloads_ver3.stat, ver3-washed-v1.diff, ver3-washed-v1.stat, ver3-washed.diff The task involves Adding and modifying the following methods, which were recently added by the JDBC4 expert group and which appeared in Mustang build 86: add PreparedStatement.setAsciiStream (int columnIndex, InputStream x, long length) add PreparedStatement.setBinaryStream (int columnIndex, InputStream x, long length add PreparedStatement.setCharacterStream (int columnIndex, Reader x, long length) add CallableStatement.setAsciiStream (String columnName, InputStream x, long length) add CallableStatement.setBinaryStream (String columnName, InputStream x, long length) add CallableStatement.setCharacterStream (String columnName, Reader x, long length) add ResultSet.updateAsciiStream (int columnIndex, InputStream x, long length) add ResultSet.updateBinaryStream (int columnIndex, InputStream x, long length) add ResultSet.updateCharacterStream (int columnIndex, Reader x, long length) add ResultSet.updateAsciiStream (String columnName, InputStream x, long length) add ResultSet.updateBinaryStream (String columnName, InputStream x, long length) add ResultSet.updateCharacterStream (String columnName, Reader x, long length) add ResultSet.updateBlob (int columnIndex, InputStream x, long length) add ResultSet.updateBlob (String columnName, InputStream x, long length) add ResultSet.updateClob (int columnIndex, Reader x, long length) add ResultSet.updateClob (String columnName, Reader x, long length) add ResultSet.updateNClob (int columnIndex, Reader x, long length) add ResultSet.updateNClob (String columnName, Reader x, long length) modify ResultSet.updateNCharacterStream(int columnIndex, Reader x, int length) to ResultSet.updateNCharacterStream(int columnIndex, Reader x, long length) modify ResultSet.updateNCharacterStream(String columnName, Reader x, int length) to ResultSet.updateNCharacterStream(String columnName, Reader x, long length) -- 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
[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=all ] Knut Anders Hatlen updated DERBY-1417: -- Derby Info: (was: [Patch Available]) Committed 'derby-1417-1a-notImplemented.diff' into trunk with revision 417753. Add new, lengthless overloads to the streaming api -- Key: DERBY-1417 URL: http://issues.apache.org/jira/browse/DERBY-1417 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Kristian Waagan Fix For: 10.2.0.0 Attachments: derby-1417-01-castsInTests.diff, derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat The JDBC4 Expert Group has approved a new set of overloads for the streaming methods. These overloads do not take a length argument. Here are the new overloads: PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream) PreparedStatement.setClob(int parameterIndex, java.io.Reader reader) PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader) CallableStatement.setAsciiStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setBinaryStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream inputStream) CallableStatement.setClob(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader reader) ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x) ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream x) ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x) ResultSet.updateBinaryStream(java.lang.String columnLabel, java.io.InputStream x, int length) ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream) ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream inputStream) ResultSet.updateClob(int columnIndex, java.io.Reader reader) ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader) ResultSet.updateNClob(int columnIndex, java.io.Reader reader) ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader) We should add these new overloads soon so that the build will not break when this methods turn up in a published Mustang build. -- 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
[jira] Commented: (DERBY-822) Client driver: Pre-fetch data on executeQuery()
[ http://issues.apache.org/jira/browse/DERBY-822?page=comments#action_12418258 ] Knut Anders Hatlen commented on DERBY-822: -- Kathey Marsden wrote: 1) Queries may fail earlier. Instead of failing on the ResultSet next() call, they may now fail on execute()/executeQuery(). Applications need to be prepared to handle this. This is correct. However, applications should already be prepared to handle errors on execute()/executeQuery(), so I hope this shouldn't cause too much trouble. 2) Prefetching may impact locking behavior. Locks may be acquired earlier or may be acquired where they never were before, promoted to table locks etc. This is partly correct. Locks for the first chunk of pre-fetched rows are aquired on execute/executeQuery instead of on the first call to next(). The locks may be acquired where they never were before, but that is only the case when there is no call to next() after the execute. Although a lot of our tests do this (in order to test that the statement compiles or to print the query execution plan), I fail to see why an application would execute a SELECT statement but not read any of the data. I do not believe locks will be promoted to table locks because of the pre-fetching. The number of rows pre-fetched when invoking executeQuery() is exactly the same as the number of rows that would be pre-fetched on the first call to next() with an old server. 3) This introduces a new difference I think between embedded and network behavior Correct. Does this sound right? If so I can take a stab and a release note. Thanks, that would be great! Is there a workaround if prefetching causes users any trouble on upgrade? The best work-around is: Do not execute SELECT statements just for fun! :) Seriously, if a select statement is executed, but the results are never read, it should probably not have been executed in the first place. Also, it might help to move the executeQuery() closer to the first call to next() (that is, don't do too much work between executeQuery() and next()). There is no simple way to disable the pre-fetching. The only ways I know of are using an updateable result set or including a LOB column in the query. Client driver: Pre-fetch data on executeQuery() --- Key: DERBY-822 URL: http://issues.apache.org/jira/browse/DERBY-822 Project: Derby Type: Improvement Components: Network Server, Performance Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: DERBY-822-v1.diff, DERBY-822-v1.stat, DERBY-822-v2.diff, DERBY-822-v2.stat, DERBY-822-v3.diff, DERBY-822-v3.stat Currently, the client driver does not pre-fetch data when executeQuery() is called, but it does on the first call to ResultSet.next(). Pre-fetching data on executeQuery() would reduce network traffic and improve performance. The DRDA protocol supports this. From the description of OPNQRY (open query): The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. -- 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
[jira] Resolved: (DERBY-1463) Resolve javadoc warnings in BrokeredCallableStatement40
[ http://issues.apache.org/jira/browse/DERBY-1463?page=all ] Knut Anders Hatlen resolved DERBY-1463: --- Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 417953. Resolve javadoc warnings in BrokeredCallableStatement40 --- Key: DERBY-1463 URL: http://issues.apache.org/jira/browse/DERBY-1463 Project: Derby Type: Bug Components: Javadoc Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: JavaDocWarnings.diff, JavaDocWarnings.stat following javadoc warnings in trunk: [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:287: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:303: warning - @param argument parameterIndex is not a parameter name. [javadoc] opensource\java\engine\org\apache\derby\iapi\jdbc\BrokeredCallableStatement40.java:319: warning - @param argument parameterIndex is not a parameter name. -- 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
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[
http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12418457 ]
Knut Anders Hatlen commented on DERBY-1393:
---
Thanks for the info, Rick! Seems like setObject() with
targetSqlType==JAVA_OBJECT should be supported too, then. For instance, this
works:
PreparedStatement ps = c.prepareStatement
(select aliasinfo from sys.sysaliases where aliasinfo = ?);
ps.setObject(1, new org.apache.derby.catalog.AliasInfo() {
public String getMethodName() {
return John Cleese;
}
});
ps.executeQuery();
It should also work when targetSqlType is specified.
PreparedStatement.setObject(Object,int,int) should throw for unsupported types
--
Key: DERBY-1393
URL: http://issues.apache.org/jira/browse/DERBY-1393
Project: Derby
Type: Bug
Components: JDBC, SQL
Versions: 10.2.0.0
Environment: JDBC 4, jdk 1.6
Reporter: Dyre Tjeldvoll
Assignee: Knut Anders Hatlen
Priority: Minor
Fix For: 10.2.0.0
From the javadoc:
Throws:
...
SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB,
CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF,
ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this
data type
Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR,
LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw
SQLFeatureNotSupportedException if used with any of these types. Currently a
general type conversion exception is thrown:
1)
testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL
Exception: An attempt was made to get a data value of type 'CLOB' from a
data value of type '2003'.
Caused by: SQL Exception: An attempt was made to get a data value of type
'CLOB' from a data value of type '2003'.
--
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
[jira] Updated: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ]
Knut Anders Hatlen updated DERBY-1393:
--
Attachment: derby-1393-v1.diff
derby-1393-v1.stat
Attached a patch for this issue (derby-1393-v1.diff). Description of
the patch:
The new setObject() methods call checkForSupportedDataType() to
check whether targetSqlType is supported.
Added a new error message The data type ''{0}'' is not supported.
with SQL state 0A000 (which ensures that the exception is converted
to SQLFeatureNotSupportedException). This error message is used when
targetSqlType is not supported.
Added more JDBC 4.0 constants (from java.sql.Types) to
JDBC40Translation and created a test JDBC40TranslationTest which
tests that the constants are correct (the values of the constants
are hard coded, so we don't get the compile-time check as with
JDBC{2,3}0Translation).
New test case SetObjectUnsupportedTest which is run as part of
PreparedStatementTest and CallableStatementTest in the jdbc40 suite.
Derbyall runs cleanly. The patch is ready for review. Thanks!
PreparedStatement.setObject(Object,int,int) should throw for unsupported types
--
Key: DERBY-1393
URL: http://issues.apache.org/jira/browse/DERBY-1393
Project: Derby
Type: Bug
Components: JDBC, SQL
Versions: 10.2.0.0
Environment: JDBC 4, jdk 1.6
Reporter: Dyre Tjeldvoll
Assignee: Knut Anders Hatlen
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1393-v1.diff, derby-1393-v1.stat
From the javadoc:
Throws:
...
SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB,
CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF,
ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this
data type
Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR,
LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw
SQLFeatureNotSupportedException if used with any of these types. Currently a
general type conversion exception is thrown:
1)
testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL
Exception: An attempt was made to get a data value of type 'CLOB' from a
data value of type '2003'.
Caused by: SQL Exception: An attempt was made to get a data value of type
'CLOB' from a data value of type '2003'.
--
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
[jira] Updated: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen updated DERBY-1393: -- Derby Info: [Patch Available] PreparedStatement.setObject(Object,int,int) should throw for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1393-v1.diff, derby-1393-v1.stat From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Commented: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=comments#action_12418650 ] Knut Anders Hatlen commented on DERBY-1364: --- I plan to commit the patch early next week. Please let me know if you have any comments or need more time to review. Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1364-v1.diff, derby-1364-v1.stat When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Updated: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ] Knut Anders Hatlen updated DERBY-1468: -- Assign To: Knut Anders Hatlen Derby Info: [Regression] Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol. Key: DERBY-1468 URL: http://issues.apache.org/jira/browse/DERBY-1468 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0 Reporter: A B Assignee: Knut Anders Hatlen When a client sends a QRYROWSET value of zero to the server, DRDA indicates that the server should not return any rows. But the current Derby Server treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) and thus performs pre-fetching (as of DERBY-822), which it shouldn't do. As a result, clients that send a QRYROWSET of 0 and do not expect data could see unexpected results--for example, the DB2 ODBC driver will return the first row of data twice for scrollable cursors because of this issue. Relevant discussion: http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659 Some quotes from DRDA manuals: 1) DRDA Manual v3 for OPNQRY: The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. 2) Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). -- 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
[jira] Updated: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ] Knut Anders Hatlen updated DERBY-1468: -- Attachment: derby-1468-v1.diff derby-1468-v1.stat The attached patch (v1) disables pre-fetching for LMTBLKPRC when QRYROWSET=0. Army could you please see if solves the issue with the ODBC driver? Since there is no way I know of to reproduce the bug with the network client driver, I have added a test case to the protocol test which sends an OPNQRY for a scrollable cursor with QRYROWSET=0. The test case fails without the patch and succeeds with the patch. I think the test case mimics the behaviour of the ODBC driver. One thing to note about the patch: It does revert the handling of the specific case to pre-822 behaviour, but it does nothing with writeQRYDTA and writeFDODTA to make them handle QRYROWSET=0. writeQRYDTA() can still be called with QRYROWSET=0 on EXCSQLSTT. I'm not sure whether that is a problem, and the code that enables this was not touched by DERBY-822. EXCSQLSTT should probably have a similar fix for completeness. (A possible way to try to provoke this with the ODBC driver could be to execute a stored procedure that returns a scrollable result set.) Derbyall runs cleanly with the patch. Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol. Key: DERBY-1468 URL: http://issues.apache.org/jira/browse/DERBY-1468 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0 Reporter: A B Assignee: Knut Anders Hatlen Attachments: derby-1468-v1.diff, derby-1468-v1.stat When a client sends a QRYROWSET value of zero to the server, DRDA indicates that the server should not return any rows. But the current Derby Server treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) and thus performs pre-fetching (as of DERBY-822), which it shouldn't do. As a result, clients that send a QRYROWSET of 0 and do not expect data could see unexpected results--for example, the DB2 ODBC driver will return the first row of data twice for scrollable cursors because of this issue. Relevant discussion: http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659 Some quotes from DRDA manuals: 1) DRDA Manual v3 for OPNQRY: The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. 2) Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). -- 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
[jira] Updated: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ] Knut Anders Hatlen updated DERBY-1468: -- Derby Info: [Patch Available, Regression] (was: [Regression]) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol. Key: DERBY-1468 URL: http://issues.apache.org/jira/browse/DERBY-1468 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0 Reporter: A B Assignee: Knut Anders Hatlen Attachments: derby-1468-v1.diff, derby-1468-v1.stat When a client sends a QRYROWSET value of zero to the server, DRDA indicates that the server should not return any rows. But the current Derby Server treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) and thus performs pre-fetching (as of DERBY-822), which it shouldn't do. As a result, clients that send a QRYROWSET of 0 and do not expect data could see unexpected results--for example, the DB2 ODBC driver will return the first row of data twice for scrollable cursors because of this issue. Relevant discussion: http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659 Some quotes from DRDA manuals: 1) DRDA Manual v3 for OPNQRY: The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. 2) Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). -- 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
[jira] Assigned: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
[ http://issues.apache.org/jira/browse/DERBY-1427?page=all ] Knut Anders Hatlen reassigned DERBY-1427: - Assign To: Knut Anders Hatlen sysinfo does not write Java SE and JDBC version when running under JDK 1.6 -- Key: DERBY-1427 URL: http://issues.apache.org/jira/browse/DERBY-1427 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 When running sysinfo with jdk 1.6 information about which Java SE and JDBC versions that is supported is missing in the output. The following is written: - Derby Information JRE - JDBC: ?-? The complete output from sysinfo: -- Java Information -- Java Version:1.6.0-beta2 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.6.0_b86/jre Java classpath: jars/sane/derby.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: os136802 Java user home: /home/os136802 Java user dir: /home/os136802/derby/develop/jdk16/trunk java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: ?-? [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha - (415258M) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (415258M) Found support for locale: [es] version: 10.2.0.4 alpha - (415258M) Found support for locale: [fr] version: 10.2.0.4 alpha - (415258M) Found support for locale: [it] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (415258M) -- -- 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
[jira] Updated: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
[ http://issues.apache.org/jira/browse/DERBY-1427?page=all ] Knut Anders Hatlen updated DERBY-1427: -- Attachment: derby-1427-v1.diff derby-1427-v1.stat The attached patch makes sysinfo print JRE - JDBC: Java SE 6 - JDBC 4.0 when running under JVM version 1.6. sysinfo does not write Java SE and JDBC version when running under JDK 1.6 -- Key: DERBY-1427 URL: http://issues.apache.org/jira/browse/DERBY-1427 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1427-v1.diff, derby-1427-v1.stat When running sysinfo with jdk 1.6 information about which Java SE and JDBC versions that is supported is missing in the output. The following is written: - Derby Information JRE - JDBC: ?-? The complete output from sysinfo: -- Java Information -- Java Version:1.6.0-beta2 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.6.0_b86/jre Java classpath: jars/sane/derby.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: os136802 Java user home: /home/os136802 Java user dir: /home/os136802/derby/develop/jdk16/trunk java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: ?-? [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha - (415258M) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (415258M) Found support for locale: [es] version: 10.2.0.4 alpha - (415258M) Found support for locale: [fr] version: 10.2.0.4 alpha - (415258M) Found support for locale: [it] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (415258M) -- -- 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
[jira] Updated: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
[ http://issues.apache.org/jira/browse/DERBY-1427?page=all ] Knut Anders Hatlen updated DERBY-1427: -- Derby Info: [Patch Available] sysinfo does not write Java SE and JDBC version when running under JDK 1.6 -- Key: DERBY-1427 URL: http://issues.apache.org/jira/browse/DERBY-1427 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1427-v1.diff, derby-1427-v1.stat When running sysinfo with jdk 1.6 information about which Java SE and JDBC versions that is supported is missing in the output. The following is written: - Derby Information JRE - JDBC: ?-? The complete output from sysinfo: -- Java Information -- Java Version:1.6.0-beta2 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.6.0_b86/jre Java classpath: jars/sane/derby.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: os136802 Java user home: /home/os136802 Java user dir: /home/os136802/derby/develop/jdk16/trunk java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: ?-? [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha - (415258M) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (415258M) Found support for locale: [es] version: 10.2.0.4 alpha - (415258M) Found support for locale: [fr] version: 10.2.0.4 alpha - (415258M) Found support for locale: [it] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (415258M) -- -- 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
[jira] Resolved: (DERBY-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6
[ http://issues.apache.org/jira/browse/DERBY-1427?page=all ] Knut Anders Hatlen resolved DERBY-1427: --- Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks, Andrew! Committed revision 418687. sysinfo does not write Java SE and JDBC version when running under JDK 1.6 -- Key: DERBY-1427 URL: http://issues.apache.org/jira/browse/DERBY-1427 Project: Derby Type: Bug Components: Tools Versions: 10.2.0.0 Environment: Sun JDK 1.6 Reporter: Olav Sandstaa Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1427-v1.diff, derby-1427-v1.stat When running sysinfo with jdk 1.6 information about which Java SE and JDBC versions that is supported is missing in the output. The following is written: - Derby Information JRE - JDBC: ?-? The complete output from sysinfo: -- Java Information -- Java Version:1.6.0-beta2 Java Vendor: Sun Microsystems Inc. Java home: /usr/local/java/jdk1.6.0_b86/jre Java classpath: jars/sane/derby.jar OS name: SunOS OS architecture: x86 OS version: 5.10 Java user name: os136802 Java user home: /home/os136802 Java user dir: /home/os136802/derby/develop/jdk16/trunk java.specification.name: Java Platform API Specification java.specification.version: 1.6 - Derby Information JRE - JDBC: ?-? [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha - (415258M) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.0.4 alpha - (415258M) Found support for locale: [es] version: 10.2.0.4 alpha - (415258M) Found support for locale: [fr] version: 10.2.0.4 alpha - (415258M) Found support for locale: [it] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ja_JP] version: 10.2.0.4 alpha - (415258M) Found support for locale: [ko_KR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [pt_BR] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_CN] version: 10.2.0.4 alpha - (415258M) Found support for locale: [zh_TW] version: 10.2.0.4 alpha - (415258M) -- -- 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
[jira] Resolved: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.
[ http://issues.apache.org/jira/browse/DERBY-1468?page=all ] Knut Anders Hatlen resolved DERBY-1468: --- Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: [Regression] (was: [Patch Available, Regression]) Thanks for the review, Army! Committed revision 418691. Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol. Key: DERBY-1468 URL: http://issues.apache.org/jira/browse/DERBY-1468 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0 Reporter: A B Assignee: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: derby-1468-v1.diff, derby-1468-v1.stat When a client sends a QRYROWSET value of zero to the server, DRDA indicates that the server should not return any rows. But the current Derby Server treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) and thus performs pre-fetching (as of DERBY-822), which it shouldn't do. As a result, clients that send a QRYROWSET of 0 and do not expect data could see unexpected results--for example, the DB2 ODBC driver will return the first row of data twice for scrollable cursors because of this issue. Relevant discussion: http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659 Some quotes from DRDA manuals: 1) DRDA Manual v3 for OPNQRY: The qryrowset parameter specifies whether a rowset of rows is to be returned with the command. This is only honored for non-dynamic scrollable cursors (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming to the limited block query protocol. The target server fetches no more than the requested number of rows. It may fetch fewer rows if it is restricted by extra query block limits, or if a fetch operation results in a negative SQLSTATE or an SQLSTATE of 02000. 2) Page 698 of V.3 says: A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the server to return no rows with the OPNQRYRM for the cursor or result set. A QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset cursors and results in the application server generating a SYNTAXRM with a SYNERRCD value of '15'x (reserved value not allowed). -- 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
[jira] Resolved: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen resolved DERBY-1364: --- Resolution: Fixed Derby Info: (was: [Patch Available]) Committed revision 418692. Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1364-v1.diff, derby-1364-v1.stat When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Commented: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=comments#action_12418941 ] Knut Anders Hatlen commented on DERBY-989: -- I have a hypothesis, but it's hard to verify since the failure is intermittent and the test needs much time to finish. I believe there are two issues: a) BasicDaemon has not enough synchronization between unsubscribe() and serviceClient() to prevent the following order of events 1. the daemon thread fetches client N from the service queue 2. another thread invokes unsubscribe(N) which removes client N from the queue 3. the daemon thread invokes performWork() on client N Because of this, it is possible that performWork() is called on an unsubscribed client, which will cause T_DaemonService.T03() to fail. b) When the error unsubscribed continue to get serviced is raised in T_DaemonService.T03(), s1 isn't resubscribed. A call to t_checkStatus() after the failure therefore hangs waiting for an unsubscribed client to be serviced. This causes the time bomb. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Assigned: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen reassigned DERBY-989: Assign To: Knut Anders Hatlen unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Commented: (DERBY-1237) unit/daemonService fails intermittently with Shutting down due to unit test failure.
[ http://issues.apache.org/jira/browse/DERBY-1237?page=comments#action_12418964 ] Knut Anders Hatlen commented on DERBY-1237: --- This could be a duplicate of DERBY-989, but it's hard to say since the real error message is hidden in derby.log. DERBY-989 mentions this error message found in derby.log: org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - unsubscribed continue to get serviced at org.apache.derbyTesting.unitTests.harness.T_Fail.testFailMsg(T_Fail.java:95) at org.apache.derbyTesting.unitTests.services.T_DaemonService.T03(T_DaemonService.java:247) at org.apache.derbyTesting.unitTests.services.T_DaemonService.runTestSet(T_DaemonService.java:118) at org.apache.derbyTesting.unitTests.harness.T_MultiThreadedIterations.run(T_MultiThreadedIterations.java:180) at java.lang.Thread.run(Thread.java:570) If this error happens before the last iteration of T03, the test will hang for an hour before it's killed and prints a time bomb message (as the bug description of DERBY-989 says). However, if the error happens in the last iteration of T03, the test won't hang and it prints Shutting down due to unit test failure as reported in this issue. unit/daemonService fails intermittently with Shutting down due to unit test failure. --- Key: DERBY-1237 URL: http://issues.apache.org/jira/browse/DERBY-1237 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden see a failure for this test with 10.2.0.0 alpha - (394001) on IBM 1.4.2 I don't see ran out of time. Is this the same failure or something different? *** Start: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:37:02 *** 2 del -- Unit Test T_DaemonService finished 2 add Shutting down due to unit test failure. Test Failed. *** End: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:46:24 ** This appears to be different than DERBY-989 as it has failed repeatedly with IBM 1.4.2 and has a diffferent error. -- 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
[jira] Assigned: (DERBY-1237) unit/daemonService fails intermittently with Shutting down due to unit test failure.
[ http://issues.apache.org/jira/browse/DERBY-1237?page=all ] Knut Anders Hatlen reassigned DERBY-1237: - Assign To: Knut Anders Hatlen unit/daemonService fails intermittently with Shutting down due to unit test failure. --- Key: DERBY-1237 URL: http://issues.apache.org/jira/browse/DERBY-1237 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Knut Anders Hatlen see a failure for this test with 10.2.0.0 alpha - (394001) on IBM 1.4.2 I don't see ran out of time. Is this the same failure or something different? *** Start: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:37:02 *** 2 del -- Unit Test T_DaemonService finished 2 add Shutting down due to unit test failure. Test Failed. *** End: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:46:24 ** This appears to be different than DERBY-989 as it has failed repeatedly with IBM 1.4.2 and has a diffferent error. -- 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
[jira] Updated: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen updated DERBY-989: - Attachment: derby-989-timebomb.diff derby-989-timebomb.stat Attached a one-line patch (derby-989-timebomb.diff) which removes the time bomb problem. The patch clears the serviceRecord vector each time runTestSet() is called. The old service records are ignored anyway if the previous iteration of the test was successful, but if a previous iteration has failed, they may cause a hang in t_checkStatus(). This patch does not fix the real problem, it only makes the test finish sooner when it fails. The failure will be reported as unit test failure not time bomb. This is the same message as reported in DERBY-1537. Derbyall ran cleanly with the patch. Reviews and comments are appreciated. Thanks! unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-timebomb.diff, derby-989-timebomb.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Updated: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen updated DERBY-989: - Attachment: derby-989-v1.diff derby-989-v1.stat The attached patch (derby-989-v1.diff) attempts to solve the real problem. Derbyall runs cleanly with the patch. I have not been able to reproduce the bug on single-CPU machines (neither with the patch nor without the patch). On dual-CPU machines I got these results with daemonService.unit: Solaris without patch: 80 runs - 5 failures Solaris with patch: 80 runs - 0 failures Linux without patch: 80 runs - 2 failures Linux with patch: 80 runs - 0 failures Description of the patch: Right before BasicDaemon invokes performWork(), it now checks (inside a synchronized block) that the client has not unsubscribed. BasicDaemon.unsubscribe() now has a synchronized block which checks whether the client that is about to be unsubscribed is being serviced. If it is being serviced, unsubscribe() waits until performWork() has finished before it returns. With this patch, the behaviour of BasicDaemon.unsubscribe() changes. Before, it would always return immediately. Now, it returns immediately if the client that wants to unsubscribe is not being serviced. Otherwise, it waits until the client's performWork() method has finished. This means that if performWork() enters a deadlock, unsubscribe() might never return. I think this is acceptable since the javadoc for BasicDaemon says: [The] performWork method should be well behaved - in other words, it should not take too long or hog too many resources or deadlock with anyone else. Comments? unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Commented: (DERBY-1237) unit/daemonService fails intermittently with Shutting down due to unit test failure.
[ http://issues.apache.org/jira/browse/DERBY-1237?page=comments#action_12419080 ] Knut Anders Hatlen commented on DERBY-1237: --- I have gone through the logs from these failures in Ole's regression testing: http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/395664-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby-10.1/testlog/CYGWIN_NT-5.2_i686-unknown/407510-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.9_sun4u-sparc/413485-unit_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/409844-unit_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.9_sun4u-sparc/409844-unit_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/415379-unit_diff.txt They are all caused by the same failure as DERBY-989 (Test failed - unsubscribed continue to get serviced). Does anyone object to closing this issue as a duplicate of 989? unit/daemonService fails intermittently with Shutting down due to unit test failure. --- Key: DERBY-1237 URL: http://issues.apache.org/jira/browse/DERBY-1237 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Knut Anders Hatlen see a failure for this test with 10.2.0.0 alpha - (394001) on IBM 1.4.2 I don't see ran out of time. Is this the same failure or something different? *** Start: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:37:02 *** 2 del -- Unit Test T_DaemonService finished 2 add Shutting down due to unit test failure. Test Failed. *** End: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:46:24 ** This appears to be different than DERBY-989 as it has failed repeatedly with IBM 1.4.2 and has a diffferent error. -- 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
[jira] Commented: (DERBY-496) unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was failed
[ http://issues.apache.org/jira/browse/DERBY-496?page=comments#action_12419150 ] Knut Anders Hatlen commented on DERBY-496: -- I believe this failure has not occurred on trunk after the check-in of DERBY-496_2_addition.patch (revision 278581). If no one wants to port the fix to the 10.1 branch, I think we can close the issue. unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was failed -- Key: DERBY-496 URL: http://issues.apache.org/jira/browse/DERBY-496 Project: Derby Type: Bug Components: Regression Test Failure Environment: [EMAIL PROTECTED]:~$ cat /proc/version Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3. 5 (Debian 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005 [EMAIL PROTECTED]:~$ java -version java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Tomohito Nakayama Assignee: Tomohito Nakayama Attachments: DERBY-496.patch, DERBY-496_2.patch, DERBY-496_2_addition.patch, derby.log As summary. I found next exception in derby.log. [main] FAIL - org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): object with diag interface), expected: (D_T_DiagTestClass1: object with diag interface). org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): object with diag interface), expected: (D_T_DiagTestClass1: object with diag interface). at org.apache.derbyTesting.unitTests.harness.T_Fail.testFailMsg(T_Fail.java:95) at org.apache.derbyTesting.unitTests.services.T_Diagnosticable.t_001(T_Diagnosticable.java:105) at org.apache.derbyTesting.unitTests.services.T_Diagnosticable.runTestSet(T_Diagnosticable.java:207) at org.apache.derbyTesting.unitTests.harness.T_MultiIterations.runTests(T_MultiIterations.java:94) at org.apache.derbyTesting.unitTests.harness.T_Generic.Execute(T_Generic.java:117) at org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runATest(BasicUnitTestManager.java:183) at org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runTests(BasicUnitTestManager.java:245) at org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.boot(BasicUnitTestManager.java:92) at org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996) at org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1834) at org.apache.derby.impl.services.monitor.BaseMonitor.startServices(BaseMonitor.java:966) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398) at org.apache.derby.impl.services.monitor.FileMonitor.init(FileMonitor.java:57) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288) at org.apache.derbyTesting.unitTests.harness.UnitTestMain.main(UnitTestMain.java:50) -- 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
[jira] Commented: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=comments#action_12419163 ] Knut Anders Hatlen commented on DERBY-989: -- Thank you Andreas and Bryan for reviewing the patch. Bryan wrote: 1) I don't really see why unsubscribe needs to block if it discovers that the service record being unsubscribed is currently performing work. Is this a necessary element of the fix, or just a side effect of the implementation? It is a necessary element of the fix. The test case that fails does the following (everything not related to the failure stripped away): 1 subscribe client 2 unsubscribe client 3 save the number of times the client has been serviced 4 do some other testing 5 check that the number of times the client has been serviced has not increased If unsubscribe() returns while the client is being serviced, parts of performWork() might be executed after 3 and before 5. Since performWork() is updating the number of times the client has been serviced, the check in 5 fails. The only way we can guarantee that performWork() is not running after 3 is by waiting in unsubscribe(). However, my fix assumes that the test is correct. I don't see anything in the code/comments saying that performWork() should never be run after unsubscribe() has returned. Actually, the javadoc in BasicDaemon says Furthermore, any Serviceable subscriptions, including onDemandOnly, must tolerate spurrious services. This could mean that the current behaviour is as expected/designed and the test should be changed. It should be as easy as changing point 5 to check that the number of times the client has been serviced has not increased by more than one. Does anyone have opinions on whether we should fix the Derby code or the test? I'm fine with either one of them. 2) I think that it is dangerous for unsubscribe to ignore interrupts while waiting for the service record to complete its work. I think that if unsubscribe gets an interrupt at this time, it should abandon the wait and return, or it should throw an exception. I agree. We can't throw an exception because it would break the contract of the DaemonService interface, but I think it's reasonable to abandon the wait and return. 3) Introducing the client number concept into the service record seems awkward, as it doesn't seem like a natural part of the service record implementation. Also, comparing client numbers as a way to answer the question is this service record already unsubscribed seems somewhat convoluted. Here are two alternate ideas that occurred to me: - perhaps we could refer to the new Service Record field as a unique id, and have an equals method to compare two ServiceRecord objects, so that we don't so directly couple the Client Number concept from Basic Daemon into the ServiceRecord class. I don't think we need to have decoupling of ServiceRecord from BasicDaemon as a goal. ServiceRecord is a package protected class and its only purpose is to aid the implementation of BasicDaemon. It is purely an implementation detail of BasicDaemon, and it is not related to the DaemonService interface in any way. - perhaps there should be an subscribed boolean flag in Service Record, with methods isSubscribed and setSubscribed so that when Basic Daemon wants to ask if a ServiceRecord is already unsubscribed, it could do so directly rather then by fetching the client number and testing it against -1 and so forth. I agree that this sounds cleaner. Thanks for the tip! 4) It seems a little odd that BasicDaemon sometimes synchronizes on the this object, and sometimes depends on the fact that subscription is a Vector and thus is inherently synchronized. I'm not saying that anything is necessarily wrong here, it was just a red flag to me that there were two levels of synchronization being used in the BasicDaemon methods. I'm not a fan of this either. However, in this case it seems like the vector synchronization and the this synchronization guard different parts of the state. Synchronization on this ensures that the state controlling the wait() loops is consistent, and the vector synchronization ensures that concurrent modifications of the vector don't interfere with each other. There is probably a cleaner way to implement BasicDaemon, but that would be outside the scope of this patch, I think. Thanks for all your comments! I will wait for comments on my question about whether this is a test issue or a code issue before submitting a new patch. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS:
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12419166 ] Knut Anders Hatlen commented on DERBY-1393: --- Hi Bryan, 1) The name of the test, (that is, the argument to org.apache.derbyTesting.functionTests.harness.RunTest) is jdbc4/JDBC40TranslationTest.junit. The file that implements the test is called JDBC40TranslationTest.java. The test harness uses the last part of the name to decide how it should run the test. If it ends with .java, the harness knows that the test is a java class with a main() method. If it ends with .junit, the harness knows it's a java class which can be run by a JUnit test runner. 2) JDBC20Translation and JDBC30Translation are located in both org.apache.derby.iapi.reference and org.apache.derby.shared.common.reference (the former used by the embedded driver and the latter by the client driver). Since constants in an interface are compiled in by the compiler, these interfaces need not be and are not part of the released jar files. The previous version of JDBC40Translation was only located in org.apache.derby.shared.common.reference, and for consistency (and because I needed the constants in the embedded driver) I created a copy in org.apache.derby.iapi.reference. Instead of making a copy of the interface, I let it the new interface extend the original one. This is also done by JDBC30Translation, and because of the way the compiler handles constants in interfaces, there is no run-time dependency between the two interfaces (actually, none of them exist at run-time). PreparedStatement.setObject(Object,int,int) should throw for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1393-v1.diff, derby-1393-v1.stat From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Created: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types
PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types - Key: DERBY-1476 URL: http://issues.apache.org/jira/browse/DERBY-1476 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Environment: JDBC 4.0 Reporter: Knut Anders Hatlen Assigned to: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 The javadoc for PreparedStatement.setNull(int, int) says: http://download.java.net/jdk6/docs/api/java/sql/PreparedStatement.html#setNull(int,%20int) Throws: ... SQLFeatureNotSupportedException - if sqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently, a general type conversion exception is thrown. With the client driver, no exception is thrown when using this method with the unsupported types. -- 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
[jira] Updated: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen updated DERBY-989: - Attachment: derby-989-testfix.diff derby-989-testfix.stat derby-989-testfix.diff is an alternative solution. This patch only changes what the test expects, not the behaviour of Derby. With this patch, the test allows the client to be serviced once after it has called unsubscribe(). Derbyall runs cleanly with the patch, and I'm not able to reproduce the failure in daemonService.unit. Comments/opinions on which solution to choose would be greatly appreciated. Thanks! unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-testfix.diff, derby-989-testfix.stat, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Commented: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=comments#action_12419280 ] Knut Anders Hatlen commented on DERBY-1248: --- I also see this failure on Linux, but not as frequently as on Solaris (had to run the test 125 times on Linux, whereas it fails after about 25 runs on Solaris). I have not been able to reproduce the failure on machines with single CPU. Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Attachments: storemore.zip I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- 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
[jira] Resolved: (DERBY-1237) unit/daemonService fails intermittently with Shutting down due to unit test failure.
[ http://issues.apache.org/jira/browse/DERBY-1237?page=all ] Knut Anders Hatlen resolved DERBY-1237: --- Resolution: Duplicate This issue is a duplicate of DERBY-989. Fix version is left blank. unit/daemonService fails intermittently with Shutting down due to unit test failure. --- Key: DERBY-1237 URL: http://issues.apache.org/jira/browse/DERBY-1237 Project: Derby Type: Test Components: Test, Regression Test Failure Versions: 10.2.0.0 Reporter: Kathey Marsden Assignee: Knut Anders Hatlen see a failure for this test with 10.2.0.0 alpha - (394001) on IBM 1.4.2 I don't see ran out of time. Is this the same failure or something different? *** Start: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:37:02 *** 2 del -- Unit Test T_DaemonService finished 2 add Shutting down due to unit test failure. Test Failed. *** End: daemonService jdk1.4.2 derbyall:unit 2006-04-14 08:46:24 ** This appears to be different than DERBY-989 as it has failed repeatedly with IBM 1.4.2 and has a diffferent error. -- 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
[jira] Updated: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Knut Anders Hatlen updated DERBY-1248: -- Attachment: linuxfailure.zip solarisfailure.zip Attaching two new zips. One for a failure on Linux and one for a failure on Solaris. They also include the database directory (extinout/mybackup/wombat). The failures have different low values, but recordCount is always 2. Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Attachments: linuxfailure.zip, solarisfailure.zip, storemore.zip I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- 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
[jira] Commented: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=comments#action_12419434 ] Knut Anders Hatlen commented on DERBY-989: -- Thanks for your comments, Suresh! I think I will just fix the test for now since it doesn't seem like the current behaviour of BasicDaemon causes any real problems, and it's not clear that unsubscribe() breaks its contract. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-testfix.diff, derby-989-testfix.stat, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Commented: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=comments#action_12419437 ] Knut Anders Hatlen commented on DERBY-989: -- Committed derby-989-timebomb.diff and derby-989-testfix.diff into trunk with revision 419479. I will also update the javadoc for BasicDaemon (and possibly DaemonService). Thanks for the suggestion, Mike. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-testfix.diff, derby-989-testfix.stat, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Created: (DERBY-1481) Client driver: ResultSet.beforeFirst() gives protocol error on scrollable, updatable result sets that are downgraded to read-only
Client driver: ResultSet.beforeFirst() gives protocol error on scrollable, updatable result sets that are downgraded to read-only - Key: DERBY-1481 URL: http://issues.apache.org/jira/browse/DERBY-1481 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Knut Anders Hatlen When a statement that produces scrollable, updatable result sets executes a query which cannot produce an updatable result set (a join for instance), ResultSet.beforeFirst() fails with the following error: Exception in thread main java.sql.SQLException: A network protocol error was encountered and the connection has been terminated: Network protocol exception: DSS length not 0 at end of same id chain parse. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:344) at org.apache.derby.client.am.ResultSet.beforeFirst(ResultSet.java:2101) at Repro.main(Repro.java:16) Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: Network protocol exception: DSS length not 0 at end of same id chain parse. The connection has been terminated. at org.apache.derby.client.am.ResultSet.flowPositioningFetch(ResultSet.java:3888) at org.apache.derby.client.am.ResultSet.moveToBeforeFirst(ResultSet.java:4149) at org.apache.derby.client.am.ResultSet.beforeFirstX(ResultSet.java:2118) at org.apache.derby.client.am.ResultSet.beforeFirst(ResultSet.java:2096) ... 1 more -- 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
[jira] Updated: (DERBY-1481) Client driver: ResultSet.beforeFirst() gives protocol error on scrollable, updatable result sets that are downgraded to read-only
[ http://issues.apache.org/jira/browse/DERBY-1481?page=all ] Knut Anders Hatlen updated DERBY-1481: -- Attachment: Repro.java Attached Repro.java which reproduces the error. Client driver: ResultSet.beforeFirst() gives protocol error on scrollable, updatable result sets that are downgraded to read-only - Key: DERBY-1481 URL: http://issues.apache.org/jira/browse/DERBY-1481 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Attachments: Repro.java When a statement that produces scrollable, updatable result sets executes a query which cannot produce an updatable result set (a join for instance), ResultSet.beforeFirst() fails with the following error: Exception in thread main java.sql.SQLException: A network protocol error was encountered and the connection has been terminated: Network protocol exception: DSS length not 0 at end of same id chain parse. The connection has been terminated. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:344) at org.apache.derby.client.am.ResultSet.beforeFirst(ResultSet.java:2101) at Repro.main(Repro.java:16) Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: Network protocol exception: DSS length not 0 at end of same id chain parse. The connection has been terminated. at org.apache.derby.client.am.ResultSet.flowPositioningFetch(ResultSet.java:3888) at org.apache.derby.client.am.ResultSet.moveToBeforeFirst(ResultSet.java:4149) at org.apache.derby.client.am.ResultSet.beforeFirstX(ResultSet.java:2118) at org.apache.derby.client.am.ResultSet.beforeFirst(ResultSet.java:2096) ... 1 more -- 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
[jira] Updated: (DERBY-1474) Add assertEquals overloads for Blob and Clob
[ http://issues.apache.org/jira/browse/DERBY-1474?page=all ] Knut Anders Hatlen updated DERBY-1474: -- Attachment: derby-1474-1c.diff I have reviewed the patch. The methods look very useful. I found one issue: assertEquals(Blob,Blob) has assertNull() on b1/b2 where the assert should be on is1/is2. Attached is an updated patch with that one fixed. Also, I fixed a spelling error in a comment and made the methods static. I will commit the new patch. Thank you, Kristian. Add assertEquals overloads for Blob and Clob Key: DERBY-1474 URL: http://issues.apache.org/jira/browse/DERBY-1474 Project: Derby Type: Sub-task Components: Test Versions: 10.2.0.0, 10.3.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Attachments: derby-1474-1a.diff, derby-1474-1a.stat, derby-1474-1b.diff, derby-1474-1c.diff Add assertEquals(Blob,Blob) and assertEquals(Clob,Clob) to BaseJDBCTestCase. The naming follows the JUnit scheme, and the methods throws an AssertionFailedError if the objects passed in are not equal. -- 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
[jira] Resolved: (DERBY-1474) Add assertEquals overloads for Blob and Clob
[ http://issues.apache.org/jira/browse/DERBY-1474?page=all ] Knut Anders Hatlen resolved DERBY-1474: --- Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Committed derby-1474-1c.diff into trunk with revision 419542. Add assertEquals overloads for Blob and Clob Key: DERBY-1474 URL: http://issues.apache.org/jira/browse/DERBY-1474 Project: Derby Type: Sub-task Components: Test Versions: 10.2.0.0, 10.3.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.2.0.0 Attachments: derby-1474-1a.diff, derby-1474-1a.stat, derby-1474-1b.diff, derby-1474-1c.diff Add assertEquals(Blob,Blob) and assertEquals(Clob,Clob) to BaseJDBCTestCase. The naming follows the JUnit scheme, and the methods throws an AssertionFailedError if the objects passed in are not equal. -- 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
[jira] Commented: (DERBY-1474) Add assertEquals overloads for Blob and Clob
[
http://issues.apache.org/jira/browse/DERBY-1474?page=comments#action_12419589 ]
Knut Anders Hatlen commented on DERBY-1474:
---
Hi Kristian,
I think your approach is good. I have a couple of comments about your
BaseTestCase.generateError() method. All of them are minor and just a
matter of taste. Please ignore them if you disagree.
1) I think I would have called it throwAssertionError() and let it
throw the error, not return it. That would make it analogous to
SanityManager.THROWASSERT().
2) You don't need reflection to generate the
junit.framework.AssertionFailedError (junit.jar is in the
classpath).
3) You could also avoid the use of reflection to generate the
java.lang.AssertionError as well. To do this, you need to modify
build.xml in the same directory as BaseTestCase.java. In the second
javac clause, make this change:
-pathelement path=${compile.classpath}/
+pathelement path=${java14compile.classpath}/
Then the classes will be compiled against the 1.4 libraries, but
since source=1.3 and target=1.3, they will run on 1.3 too. With
this change, generateError() could be written as simple as this:
Error error = null;
if (JVMInfo.JDK_ID = JVMInfo.J2SE_13) {
error = new AssertionFailedError(msg + : + cause.getMessage());
cause.printStackTrace();
} else {
error = new AssertionError(msg);
error.initCause(cause);
}
return error;
This approach is also used in the client driver.
Add assertEquals overloads for Blob and Clob
Key: DERBY-1474
URL: http://issues.apache.org/jira/browse/DERBY-1474
Project: Derby
Type: Sub-task
Components: Test
Versions: 10.2.0.0, 10.3.0.0
Reporter: Kristian Waagan
Assignee: Kristian Waagan
Fix For: 10.2.0.0
Attachments: derby-1474-1a.diff, derby-1474-1a.stat, derby-1474-1b.diff,
derby-1474-1c.diff, derby-1474-2a.diff, derby-1474-2a.stat, error-output.txt
Add assertEquals(Blob,Blob) and assertEquals(Clob,Clob) to BaseJDBCTestCase.
The naming follows the JUnit scheme, and the methods throws an
AssertionFailedError if the objects passed in are not equal.
--
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
[jira] Commented: (DERBY-1474) Add assertEquals overloads for Blob and Clob
[ http://issues.apache.org/jira/browse/DERBY-1474?page=comments#action_12419669 ] Knut Anders Hatlen commented on DERBY-1474: --- Committed derby-1474-2b.diff into trunk with revision 419848. Add assertEquals overloads for Blob and Clob Key: DERBY-1474 URL: http://issues.apache.org/jira/browse/DERBY-1474 Project: Derby Type: Sub-task Components: Test Versions: 10.2.0.0, 10.3.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Fix For: 10.2.0.0 Attachments: derby-1474-1a.diff, derby-1474-1a.stat, derby-1474-1b.diff, derby-1474-1c.diff, derby-1474-2a.diff, derby-1474-2a.stat, derby-1474-2b.diff, error-output.txt Add assertEquals(Blob,Blob) and assertEquals(Clob,Clob) to BaseJDBCTestCase. The naming follows the JUnit scheme, and the methods throws an AssertionFailedError if the objects passed in are not equal. -- 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
[jira] Updated: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen updated DERBY-989: - Attachment: derby-989-javadoc.diff derby-989-javadoc.stat Attaching a patch which updates the javadoc for DaemonService and BasicDaemon with information about the case where unsubscribe() is called when the client is being serviced. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-javadoc.diff, derby-989-javadoc.stat, derby-989-testfix.diff, derby-989-testfix.stat, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Resolved: (DERBY-1000) For LDAP authentication: derby.authentication.server should support ldaps:// as part of the server url.
[ http://issues.apache.org/jira/browse/DERBY-1000?page=all ] Knut Anders Hatlen resolved DERBY-1000: --- Fix Version: 10.2.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) I think the doc patch is ready to be committed too. Code patch committed with revision 419852. Doc patch committed with revision 419853. Thanks to Anders for fixing the code and updating the documentation. Thanks to Sunitha for reviewing the changes. For LDAP authentication: derby.authentication.server should support ldaps:// as part of the server url. --- Key: DERBY-1000 URL: http://issues.apache.org/jira/browse/DERBY-1000 Project: Derby Type: Bug Components: Newcomer, Security Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2, 10.2.0.0 Environment: all Reporter: Sunitha Kambhampati Assignee: Anders Morken Priority: Trivial Fix For: 10.2.0.0 Attachments: DERBY-1000.patch, DERBY1000-docs.patch derby.authentication.server does not recognize secure ldap url - ie if the url starts with ldaps:// Trying to connect using LDAP authentication with the following properties set derby.authentication.provider=LDAP derby.authentication.server=ldaps://xyz.abc.com:636 derby.authentication.ldap.searchBase='ou=xyz,o=abc.com' derby.authentication.ldap.searchFilter='(emailaddress=%USERNAME%)' derby.connection.requireAuthentication=true throws InvalidNameException ij connect 'jdbc:derby:testdb;user=a;password=p'; ERROR 08004: Connection refused : javax.naming.InvalidNameException: Invalid name: /xyz.abc.com:636 Code - LDAPAuthenticationSchemeImpl#setJNDIProviderProperties. Problem is the code expects that if Context.PROVIDER_URL is not and if derby.authentication.server is set, then the ldapServer is either of the format //server:port or it already starts with ldap:// else it just adds ldap:// . Thus for a ldaps://xyz.com:636 url , it will become ldap://ldaps://xyz.com:636 in the code snippet, dflLDAPURL is ldap:// if (ldapServer.startsWith(dfltLDAPURL)) this.providerURL = ldapServer; else if (ldapServer.startsWith(//)) this.providerURL = ldap: + ldapServer; else this.providerURL = dfltLDAPURL + ldapServer; } initDirContextEnv.put(Context.PROVIDER_URL, providerURL); We should support specifiying secure ldap , ie ldaps:// in the derby.authentication.server. Add condition to support the ldaps:// ie. if (ldapServer.startsWith(dfltLDAPURL) || ldapServer.startsWith(ldaps://)) this.providerURL = ldapServer; A workaround to the problem is to set the Context.PROVIDER_URL instead. -- 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
[jira] Updated: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Knut Anders Hatlen updated DERBY-1248: -- Attachment: solaris-singlecpu.zip Now I have seen this failure on a single-CPU machine as well. I was running derbyall on a Pentium 4, 2.66 GHz, Solaris 10. Attached log and db in solaris-singlecpu.zip. Note that the test failed with recordCount=0, not 2 as the previous failures. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 7, recordCount = 0: org.apache.derby.shared.common.sanity.AssertFailure'. Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Attachments: linuxfailure.zip, solaris-singlecpu.zip, solarisfailure.zip, storemore.zip, test2_379.jar, test335.jar I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- 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
[jira] Commented: (DERBY-1393) PreparedStatement.setObject(Object,int,int) should throw for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=comments#action_12419689 ] Knut Anders Hatlen commented on DERBY-1393: --- Hi Bryan, did you have more comments to the patch? If not, I plan to commit it next week. Thanks! PreparedStatement.setObject(Object,int,int) should throw for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1393-v1.diff, derby-1393-v1.stat From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Commented: (DERBY-1274) Network Server does not shutdown the databases it has booted when started and shutdown from the command line
[ http://issues.apache.org/jira/browse/DERBY-1274?page=comments#action_12419694 ] Knut Anders Hatlen commented on DERBY-1274: --- Hi Fernanda, If I understand your patch correctly, using NetworkServerControl from version 10.2 to stop a 10.1 network server will cause a protocol error. Is that true? Do we really need to distinguish between whether the stop was requested from command line or not? I think we only need to know whether the network server was started from command line. If it was started from command line, it should always shut down the databases before exiting. If we don't care how the server was stopped, only how it was started, then we don't need to change the protocol. Network Server does not shutdown the databases it has booted when started and shutdown from the command line Key: DERBY-1274 URL: http://issues.apache.org/jira/browse/DERBY-1274 Project: Derby Type: Bug Components: Network Server Versions: 10.2.0.0, 10.1.2.3 Reporter: Kathey Marsden Assignee: Fernanda Pizzorno Attachments: derby-1274.diff, derby-1274.stat If network server is started and shutdown from the comand line t does not shutdown the database. This can is evidenced by the fact that the db.lck file remains after the following steps. java org.apache.derby.drda.NetworkServerControl start some database access java org.apache.derby.drda.NetworkServerControl shutdown There is much discussion about the correct behavior of NetworkServer in this regard related to embedded server scenarios in DERBY-51, but it seems clear in this case the databases should be shutdown. -- 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
[jira] Created: (DERBY-1484) Client and embedded behave differently when the table name is null in DatabaseMetaData methods
Client and embedded behave differently when the table name is null in DatabaseMetaData methods -- Key: DERBY-1484 URL: http://issues.apache.org/jira/browse/DERBY-1484 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Priority: Minor When giving null as table name to getBestRowIdentifier, getColumnPrivileges, getIndexInfo, getVersionColumns or getPrimaryKeys, the client driver fails with SQLException: Table name can not be null. Embedded uses null as a wildcard and does not fail. Embedded and client should have the same behaviour. -- 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
[jira] Updated: (DERBY-1248) Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql
[ http://issues.apache.org/jira/browse/DERBY-1248?page=all ] Knut Anders Hatlen updated DERBY-1248: -- Attachment: test5.zip Attached 'test5.zip' which contains logs/db from a failure in OnlineBackupTest5.sql. Assert failure in BasePage.shiftUp() when running store/onlineBackupTest4.sql - Key: DERBY-1248 URL: http://issues.apache.org/jira/browse/DERBY-1248 Project: Derby Type: Bug Components: Store, Regression Test Failure Versions: 10.2.0.0 Environment: Sun JVM 1.5.0_04 on Solaris 10 x86. Derby from trunk (revision 396285). Sane build. Reporter: Knut Anders Hatlen Attachments: derby_335.log, linuxfailure.zip, solaris-singlecpu.zip, solarisfailure.zip, storemore.zip, test2_379.jar, test335.jar, test5.zip I saw this error when I ran derbyall. * Diff file derbyall/storeall/storemore/onlineBackupTest4.diff *** Start: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:50 *** 68 del ij(CONNECTION1) select * from ctest; 69 del ID |NAME 70 del 71 del 1 |derby backup/compress test 72 del 2 |derby backup/compress test 73 del 300|derby backup/compress test 74 del 509|derby backup/compress test 75 del 510|derby backup/compress test 76 del 511|derby backup/compress test 77 del 512|derby backup/compress test 78 del ij(CONNECTION1) insert into ctest values(2000, 'restore was successfil') ; 79 del 1 row inserted/updated/deleted 80 del ij(CONNECTION1) 80 add org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2 ERROR XJ040: Failed to start database 'wombat', see the next exception for details. ERROR XJ001: Java exception: 'ASSERT FAILED shiftUp failed, low must be between 0 and recordCount. low = 140, recordCount = 2: org.apache.derby.shared.common.sanity.AssertFailure'. ij select * from ctest; IJ ERROR: Unable to establish connection ij insert into ctest values(2000, 'restore was successfil') ; IJ ERROR: Unable to establish connection ij Test Failed. *** End: onlineBackupTest4 jdk1.5.0_04 storeall:storemore 2006-04-24 11:51:56 *** The test usually succeeds, but I managed to reproduce the failure by running this loop in the shell: touch onlineBackupTest4.pass while [ -f onlineBackupTest4.pass ]; do rm onlineBackupTest4.pass java org.apache.derbyTesting.functionTests.harness.RunTest store/onlineBackupTest4.sql done -- 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
[jira] Updated: (DERBY-1393) PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen updated DERBY-1393: -- Summary: PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types (was: PreparedStatement.setObject(Object,int,int) should throw for unsupported types) PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1393-v1.diff, derby-1393-v1.stat From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Resolved: (DERBY-1393) PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1393?page=all ] Knut Anders Hatlen resolved DERBY-1393: --- Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks Bryan! Committed revision 420436. PreparedStatement.setObject(int,Object,int) should throw SQLFeatureNotSupportedException for unsupported types -- Key: DERBY-1393 URL: http://issues.apache.org/jira/browse/DERBY-1393 Project: Derby Type: Bug Components: JDBC, SQL Versions: 10.2.0.0 Environment: JDBC 4, jdk 1.6 Reporter: Dyre Tjeldvoll Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1393-v1.diff, derby-1393-v1.stat From the javadoc: Throws: ... SQLFeatureNotSupportedException - if targetSqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently a general type conversion exception is thrown: 1) testSetObjectNotImplementedARRAY(org.apache.derbyTesting.functionTests.tests.jdbc4.PreparedStatementTest)SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. Caused by: SQL Exception: An attempt was made to get a data value of type 'CLOB' from a data value of type '2003'. -- 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
[jira] Closed: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
[ http://issues.apache.org/jira/browse/DERBY-1364?page=all ] Knut Anders Hatlen closed DERBY-1364: - Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate() - Key: DERBY-1364 URL: http://issues.apache.org/jira/browse/DERBY-1364 Project: Derby Type: Bug Components: JDBC, Network Client Versions: 10.1.2.1, 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1364-v1.diff, derby-1364-v1.stat When executing a stored procedure with executeQuery() and the proc doesn't return exactly one result set, the query should fail and the statement should be rolled back. Embedded does this correctly. The client driver, however, does not roll back the statement, so the effects of statements executed on nested connections in the stored procedure are still visible. The reason for this is that the network server executes the statement with execute() instead of executeQuery(), so that it succeeds on the server. The client then counts the number of result sets, and raises an exception if it is not one, but it does not roll back the effects of the stored procedure. verified that.) The same problem exists for executeUpdate(). JCC also has these problems. -- 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
[jira] Closed: (DERBY-1039) Database creation should fail if specified log device path already exists
[ http://issues.apache.org/jira/browse/DERBY-1039?page=all ] Knut Anders Hatlen closed DERBY-1039: - Database creation should fail if specified log device path already exists - Key: DERBY-1039 URL: http://issues.apache.org/jira/browse/DERBY-1039 Project: Derby Type: Improvement Components: Newcomer, Store Versions: 10.2.0.0, 10.1.2.1, 10.3.0.0 Reporter: Knut Anders Hatlen Assignee: Suresh Thalamati Fix For: 10.1.3.0, 10.2.0.0, 10.1.2.4 Attachments: derby-1039.diff, logd.sql If a database is created with logDevice pointing to a directory containing old log files, one might experience errors during recovery. ERROR XSDB4: Page Page(0,Container(0, 768)) is at version 2,657, the log file contains change version 2,715, either there are log records of this page missing, or this page did not get written out to disk properly. To avoid this problem, database creation should fail if logDevice is pointing to an existing directory. -- 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
[jira] Created: (DERBY-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)
EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String) - Key: DERBY-1493 URL: http://issues.apache.org/jira/browse/DERBY-1493 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that [if] the parameter does not have a user-defined or REF type, the given typeName is ignored. The client driver correctly ignores typeName. -- 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
[jira] Updated: (DERBY-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)
[ http://issues.apache.org/jira/browse/DERBY-1493?page=all ] Knut Anders Hatlen updated DERBY-1493: -- Description: The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that [if] the parameter does not have a user-defined or REF type, the given typeName is ignored. The client driver correctly ignores typeName and forwards the call to setNull(int, int). Embedded should be changed to match the client. (was: The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that [if] the parameter does not have a user-defined or REF type, the given typeName is ignored. The client driver correctly ignores typeName.) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String) - Key: DERBY-1493 URL: http://issues.apache.org/jira/browse/DERBY-1493 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that [if] the parameter does not have a user-defined or REF type, the given typeName is ignored. The client driver correctly ignores typeName and forwards the call to setNull(int, int). Embedded should be changed to match the client. -- 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
[jira] Created: (DERBY-1494) PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client
PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client Key: DERBY-1494 URL: http://issues.apache.org/jira/browse/DERBY-1494 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Priority: Minor When PreparedStatement.setNull(int, int) is called, the embedded driver will check whether the sqlType parameter specifies a type which is compatible with the actual parameter type. If the types are not compatible, an exception is thrown. The client driver does not check whether the types are compatible, and does not throw an exception. Both drivers behave according to the spec, but one of them should be changed to match the other one. -- 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
[jira] Commented: (DERBY-1494) PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client
[ http://issues.apache.org/jira/browse/DERBY-1494?page=comments#action_12420005 ] Knut Anders Hatlen commented on DERBY-1494: --- Although both implementations of setNull(int,int) are compliant, I think it would make more sense to change the embedded driver to match the client driver than vice versa. The embedded driver doesn't use the sqlType parameter for other purposes than checking type compatibility. Since null is compatible with all types in Derby, the type parameter could just as well be ignored. Changing embedded to match the client would cause less cases to fail and make it easier to move from DMBSs which treat the type parameter more liberally (for instance, MySQL, PostgreSQL and HSQLDB). PreparedStatement.setNull(int, int) checks type compatibility on embedded, but not on the client Key: DERBY-1494 URL: http://issues.apache.org/jira/browse/DERBY-1494 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Priority: Minor When PreparedStatement.setNull(int, int) is called, the embedded driver will check whether the sqlType parameter specifies a type which is compatible with the actual parameter type. If the types are not compatible, an exception is thrown. The client driver does not check whether the types are compatible, and does not throw an exception. Both drivers behave according to the spec, but one of them should be changed to match the other one. -- 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
[jira] Resolved: (DERBY-989) unit/daemonService.unit fails intermittently: 'ran out of time'
[ http://issues.apache.org/jira/browse/DERBY-989?page=all ] Knut Anders Hatlen resolved DERBY-989: -- Fix Version: 10.2.0.0 Resolution: Fixed Thank you for looking at the patch, Bryan! Committed 'derby-989-javadoc.diff' into trunk with revision 420465. unit/daemonService.unit fails intermittently: 'ran out of time' --- Key: DERBY-989 URL: http://issues.apache.org/jira/browse/DERBY-989 Project: Derby Type: Test Components: Regression Test Failure Versions: 10.2.0.0 Environment: OS: Solaris 10 3/05 s10_74L2a X86 - SunOS 5.10 Generic, JVM: Sun Microsystems Inc. 1.5.0_04 OS: Solaris 9 9/04 s9s_u7wos_09 SPARC - SunOS 5.9 Generic_118558-11, JVM: Sun Microsystems Inc. 1.5.0_03 OS: Red Hat Enterprise Linux AS release 3 (Taroon Update 4) - Linux 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:50:31 EST 2004 GNU/Linux, JVM: Sun Microsystems Inc. 1.5.0_03 Reporter: Ole Solberg Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: 989-411220-derbyall_derbyall_unit_unit_derby.log, derby-989-javadoc.diff, derby-989-javadoc.stat, derby-989-testfix.diff, derby-989-testfix.stat, derby-989-timebomb.diff, derby-989-timebomb.stat, derby-989-v1.diff, derby-989-v1.stat Signature: * Diff file unit/unit/daemonService.diff *** Start: daemonService jdk1.5.0_04 unit:unit 2006-02-14 20:46:42 *** 2 del -- Unit Test T_DaemonService finished 2 add ran out of time Shutting down due to unit test failure. Exit due to time bomb Test Failed. *** End: daemonService jdk1.5.0_04 unit:unit 2006-02-14 21:47:13 *** http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-377800.html [SunOS-5.10 i86pc-i386] -- 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
[jira] Commented: (DERBY-1330) Provide runtime privilege checking for grant/revoke functionality
[ http://issues.apache.org/jira/browse/DERBY-1330?page=comments#action_12420027 ] Knut Anders Hatlen commented on DERBY-1330: --- I have seen this regression test failure a couple of times lately. Could it be related to this issue? * Diff file derbyall/derbylang/grantRevokeDDL.diff *** Start: grantRevokeDDL jdk1.5.0_04 derbyall:derbylang 2006-07-10 09:56:26 *** 560 del ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V22'. 560a560 ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21'. Test Failed. *** End: grantRevokeDDL jdk1.5.0_04 derbyall:derbylang 2006-07-10 09:56:37 *** It seems to happen on both Solaris and Linux, JVM 1.4 and 1.5: http://www.multinet.no/~solberg/public/Apache/Derby/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/420328-derbylang_diff.txt http://www.multinet.no/~solberg/public/Apache/Derby/testlog/SunOS-5.10_i86pc-i386/420328-derbylang_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/Linux-2.6.9-34.ELsmp_x86_64-x86_64/420328-derbyall_diff.txt http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/testlog/SunOS-5.10_i86pc-i386/420328-derbyall_diff.txt It does not happen on the tinderbox, though. Provide runtime privilege checking for grant/revoke functionality - Key: DERBY-1330 URL: http://issues.apache.org/jira/browse/DERBY-1330 Project: Derby Type: Sub-task Components: SQL Versions: 10.2.0.0 Reporter: Mamta A. Satoor Assignee: Mamta A. Satoor Attachments: AuthorizationModelForDerbySQLStandardAuthorization.html, AuthorizationModelForDerbySQLStandardAuthorizationV2.html, Derby1330PrivilegeCollectionV2diff.txt, Derby1330PrivilegeCollectionV2stat.txt, Derby1330PrivilegeCollectionV3diff.txt, Derby1330PrivilegeCollectionV3stat.txt, Derby1330ViewPrivilegeCollectionV1diff.txt, Derby1330ViewPrivilegeCollectionV1stat.txt Additional work needs to be done for grant/revoke to make sure that only users with required privileges can access various database objects. In order to do that, first we need to collect the privilege requirements for various database objects and store them in SYS.SYSREQUIREDPERM. Once we have this information then when a user tries to access an object, the required SYS.SYSREQUIREDPERM privileges for the object will be checked against the user privileges in SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS. The database object access will succeed only if the user has the necessary privileges. SYS.SYSTABLEPERMS, SYS.SYSCOLPERMS and SYS.SYSROUTINEPERMS are already populated by Satheesh's work on DERBY-464. But SYS.SYSREQUIREDPERM doesn't have any information in it at this point and hence no runtime privilege checking is getting done at this point. -- 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
[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api
[ http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12420034 ] Knut Anders Hatlen commented on DERBY-1417: --- derby-1417-2a-rstest-refactor.diff looks good. Committed revision 420497. Add new, lengthless overloads to the streaming api -- Key: DERBY-1417 URL: http://issues.apache.org/jira/browse/DERBY-1417 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: Rick Hillegas Assignee: Kristian Waagan Fix For: 10.2.0.0 Attachments: derby-1417-01-castsInTests.diff, derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, derby-1417-2a-rstest-refactor.diff The JDBC4 Expert Group has approved a new set of overloads for the streaming methods. These overloads do not take a length argument. Here are the new overloads: PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x) PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader reader) PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream) PreparedStatement.setClob(int parameterIndex, java.io.Reader reader) PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader) CallableStatement.setAsciiStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setBinaryStream(java.lang.String parameterName, java.io.InputStream x) CallableStatement.setCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNCharacterStream(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream inputStream) CallableStatement.setClob(java.lang.String parameterName, java.io.Reader reader) CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader reader) ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x) ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream x) ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x) ResultSet.updateBinaryStream(java.lang.String columnLabel, java.io.InputStream x, int length) ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x) ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader x) ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream) ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream inputStream) ResultSet.updateClob(int columnIndex, java.io.Reader reader) ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader) ResultSet.updateNClob(int columnIndex, java.io.Reader reader) ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader) We should add these new overloads soon so that the build will not break when this methods turn up in a published Mustang build. -- 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
[jira] Updated: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1476?page=all ]
Knut Anders Hatlen updated DERBY-1476:
--
Attachment: derby-1476-v1.diff
derby-1476-v1.stat
derby-1476-v1.diff adds a call to checkForSupportedDataType() in setNull(). It
also moves that call in setObject() after 'if (obj == null) { setNull(pos,
type); return; }' in order to avoid double checking. New test cases have been
added to SetObjectUnsupportedTest so that it tests setObject(int,Object,int),
setObject(int,Object,int,int), setNull(int,int) and setNull(int,int,String).
With this patch, setNull() and setObject() throw
SQLFeatureNotSupportedException when running on JVM 1.6 and the specified
sqlType is unsupported.
Derbyall ran cleanly (with the exception of grantRevokeDDL which also is seen
in the Ole's regression tests). The patch is ready for review. Thanks!
PreparedStatement.setNull(int,int) should throw
SQLFeatureNotSupportedException for unsupported types
-
Key: DERBY-1476
URL: http://issues.apache.org/jira/browse/DERBY-1476
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.2.0.0
Environment: JDBC 4.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
Fix For: 10.2.0.0
Attachments: derby-1476-v1.diff, derby-1476-v1.stat
The javadoc for PreparedStatement.setNull(int, int) says:
http://download.java.net/jdk6/docs/api/java/sql/PreparedStatement.html#setNull(int,%20int)
Throws:
...
SQLFeatureNotSupportedException - if sqlType is a ARRAY, BLOB, CLOB,
DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID,
SQLXML or STRUCT data type and the JDBC driver does not support this data type
Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR,
LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw
SQLFeatureNotSupportedException if used with any of these types. Currently, a
general type conversion exception is thrown. With the client driver, no
exception is thrown when using this method with the unsupported types.
--
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
[jira] Updated: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1476?page=all ] Knut Anders Hatlen updated DERBY-1476: -- Derby Info: [Patch Available] PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types - Key: DERBY-1476 URL: http://issues.apache.org/jira/browse/DERBY-1476 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Environment: JDBC 4.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1476-v1.diff, derby-1476-v1.stat The javadoc for PreparedStatement.setNull(int, int) says: http://download.java.net/jdk6/docs/api/java/sql/PreparedStatement.html#setNull(int,%20int) Throws: ... SQLFeatureNotSupportedException - if sqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently, a general type conversion exception is thrown. With the client driver, no exception is thrown when using this method with the unsupported types. -- 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
[jira] Resolved: (DERBY-1502) Non-deterministic behavior of lang/grantRevokeDDL.sql
[ http://issues.apache.org/jira/browse/DERBY-1502?page=all ] Knut Anders Hatlen resolved DERBY-1502: --- Resolution: Fixed Derby Info: (was: [Patch Available]) Thanks Mamta! Committed revision 421179. Non-deterministic behavior of lang/grantRevokeDDL.sql - Key: DERBY-1502 URL: http://issues.apache.org/jira/browse/DERBY-1502 Project: Derby Type: Bug Components: Regression Test Failure Versions: 10.2.0.0 Environment: linux, jdk1.4 and jdk 1.5 Reporter: Rick Hillegas Assignee: Mamta A. Satoor Fix For: 10.2.0.0 Attachments: Derby1330TestErrorMessageSedDiff.txt Sometimes I see the following failure in lang/grantRevokeDDL.sql. I have seen this on linux under jdk 1.4 and 1.5. 560 del ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V22'. 560a560 ERROR 28508: User 'MAMTA3' does not have select permission on column 'C111' of table 'MAMTA2'.'V21'. Test Failed. *** End: grantRevokeDDL jdk1.4.2_08 2006-07-11 13:38:51 *** It would appear that when two permissions are inadequate, it's not clear which one will fail the statement. -- 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
[jira] Commented: (DERBY-1501) PreparedStatement#setNull(int parameterIndex, int sqlType) throws SQL Exception if given sqlType is LONGVARBINARY in embedded mode
[ http://issues.apache.org/jira/browse/DERBY-1501?page=comments#action_12420549 ] Knut Anders Hatlen commented on DERBY-1501: --- Kristian wrote: But what about the second issue? The embedded driver determines if the type of the parameter is compatible with the specified SQL type. Currently, BLOB is not seen to be compatible with BINARY, VARBINARY or LONGVARBINARY. The same goes for CLOB and the character types. I think the embedded driver might be doing the right thing. I have no problem understanding the logic in DataTypeDescriptor when I look at table B-5 in the JDBC 4 spec, but the table is for setObject. Can anyone weigh in on this? I think table B-5 is the correct place to determine which types should be considered compatible in setNull(). Therefore, embedded does not violate the spec when it raises an exception. However, I also think the client behaviour is compliant. The javadoc for setNull(int,int) says nothing about this issue, but the javadoc for setNull(int,int,String) says: If a JDBC driver does not need the type code or type name information, it may ignore it. Derby doesn't need the type code, so ignoring it would be OK. PreparedStatement#setNull(int parameterIndex, int sqlType) throws SQL Exception if given sqlType is LONGVARBINARY in embedded mode -- Key: DERBY-1501 URL: http://issues.apache.org/jira/browse/DERBY-1501 Project: Derby Type: Bug Versions: 10.1.1.0 Environment: WindowsXP Reporter: Markus Fuchs Attachments: ByteArrayTest.java When inserting a row into following table BYTEARRAY_TEST( ID int, BYTEARRAY_VAL blob) PreparedStatement#setNull(int parameterIndex, int sqlType) throws SQL Exception if given sqlType is LONGVARBINARY. You must give sqlType BLOB to make the insert work. The same test works using sqlType LONGVARBINARY in network mode. The following combinations don't work: Column type sqlType not working mandatory sqlType BLOB LONGVARBINARY BLOB CLOB LONGVARCHARCLOB The issue here is that first Derby behaves differently in network and embedded mode. And secondly, should accept LONGVARBINARY/LONGVARCHAR for BLOB/CLOB columns. -- 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
[jira] Created: (DERBY-1503) Make jdbc4/StatementEventsTest.junit test callable statements
Make jdbc4/StatementEventsTest.junit test callable statements - Key: DERBY-1503 URL: http://issues.apache.org/jira/browse/DERBY-1503 Project: Derby Type: Improvement Components: JDBC, Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assigned to: Knut Anders Hatlen Priority: Minor Currently, StatementEventsTest only tests that statement events work with prepared statements. It should also test callable statements. -- 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
[jira] Updated: (DERBY-1503) Make jdbc4/StatementEventsTest.junit test callable statements
[ http://issues.apache.org/jira/browse/DERBY-1503?page=all ] Knut Anders Hatlen updated DERBY-1503: -- Attachment: derby-1503-v1.diff The attached patch changes StatementEventsTest the following way: 1) New methods setXA() and setCallable() which make it possible to use the same test method to test XAConnection/PooledConnection and PreparedStatement/CallableStatement. 2) Split the test methods into smaller ones. 3) Use asserts to report errors instead of System.out.println(). Make jdbc4/StatementEventsTest.junit test callable statements - Key: DERBY-1503 URL: http://issues.apache.org/jira/browse/DERBY-1503 Project: Derby Type: Improvement Components: JDBC, Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Attachments: derby-1503-v1.diff Currently, StatementEventsTest only tests that statement events work with prepared statements. It should also test callable statements. -- 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
[jira] Closed: (DERBY-1503) Make jdbc4/StatementEventsTest.junit test callable statements
[ http://issues.apache.org/jira/browse/DERBY-1503?page=all ] Knut Anders Hatlen closed DERBY-1503: - Fix Version: 10.2.0.0 Resolution: Fixed Committed revision 421218. Make jdbc4/StatementEventsTest.junit test callable statements - Key: DERBY-1503 URL: http://issues.apache.org/jira/browse/DERBY-1503 Project: Derby Type: Improvement Components: JDBC, Test Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1503-v1.diff Currently, StatementEventsTest only tests that statement events work with prepared statements. It should also test callable statements. -- 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
[jira] Commented: (DERBY-323) Locale problem in test of derby
[ http://issues.apache.org/jira/browse/DERBY-323?page=comments#action_12420598 ] Knut Anders Hatlen commented on DERBY-323: -- The DERBY-1352 fix didn't completely fix this issue. When I ran derbyall with Japanese locale, the nist tests and some tests that execute a java process failed. I think I have a fix for this in my sandbox. I am currently running derbyall to verify that it actually fixes the issue. Locale problem in test of derby --- Key: DERBY-323 URL: http://issues.apache.org/jira/browse/DERBY-323 Project: Derby Type: Bug Components: Test Environment: Japanese localed Windows using cygwiin Reporter: Tomohito Nakayama Many of derbyall fails at Japanese localed Windows when environment corresponding derbyLocale_JP.jar exists in CLASSPATH. Almost all of derby_all was failed because all result message was generated in Japanese , and that was different from master file. I tried next configuration ... conf_0:Exclude derbyLocale_jp.jar conf_1:Add option -Duser.language=en -Duser.country=US conf_2:Add option -Djvmflags=-Duser.language=en -Duser.country=US conf_3:Defiine environment variable _JAVA_OPTIONS=:-Duser.language=en -Duser.locale=us conf_4:Defiine environment variable LC_CTYPE:en_US conf_0 works well on derbyall suite but some of derbynetclientmats/derbynetmats in derbyall suite was failed. Network module seems to have localed message in other resource. conf_1 works on derbynetclientsmats suite, but same configuration for derbyall suite does not work at all. conf_2 does not work on derbynetclientsmats suite. conf_3 seems to work for locale problem but Picked up _JAVA_OPTIONS: message cause error in test. conf_4 does not works ... Now conf_0 seems to be reasonable method now. I think conf_3 may be reasonable direction to modify test suite. -- 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
[jira] Closed: (DERBY-1476) PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types
[ http://issues.apache.org/jira/browse/DERBY-1476?page=all ] Knut Anders Hatlen closed DERBY-1476: - Resolution: Fixed Derby Info: (was: [Patch Available]) Committed revision 421255. PreparedStatement.setNull(int,int) should throw SQLFeatureNotSupportedException for unsupported types - Key: DERBY-1476 URL: http://issues.apache.org/jira/browse/DERBY-1476 Project: Derby Type: Bug Components: JDBC Versions: 10.2.0.0 Environment: JDBC 4.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Priority: Minor Fix For: 10.2.0.0 Attachments: derby-1476-v1.diff, derby-1476-v1.stat The javadoc for PreparedStatement.setNull(int, int) says: http://download.java.net/jdk6/docs/api/java/sql/PreparedStatement.html#setNull(int,%20int) Throws: ... SQLFeatureNotSupportedException - if sqlType is a ARRAY, BLOB, CLOB, DATALINK, JAVA_OBJECT, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT data type and the JDBC driver does not support this data type Since Derby doesn't support ARRAY, DATALINK, NCHAR, NCLOB, NVARCHAR, LONGNVARCHAR, REF, ROWID, SQLXML or STRUCT the method should throw SQLFeatureNotSupportedException if used with any of these types. Currently, a general type conversion exception is thrown. With the client driver, no exception is thrown when using this method with the unsupported types. -- 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
