db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "TenTenOneBuddyTesting" by DagWanvik
Date Mon, 25 Feb 2013 06:58:04 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "TenTenOneBuddyTesting" page has been changed by DagWanvik:
http://wiki.apache.org/db-derby/TenTenOneBuddyTesting?action=diff&rev1=1&rev2=2

  Describe TenTenOneBuddyTesting here.
+ '''Objective''': Facilitate evaluation of the new features added to 10.10.
  
+ 'Buddy Testing', wherein contributors test Derby 10.10 features added
+ by other members. Each contributor is encouraged to signup for testing
+ and providing feedback on multiple features. A single feature can also
+ have multiple buddy testers, the more the better.
+ 
+ The test scenarios could be, functionality testing, integration
+ testing, stress/load testing etc. using the newly added features in
+ 10.10. Tests should include documentation review, both javadoc and
+ user documentation where applicable. It would be great if any (junit)
+ test written could be contributed back to Derby so that others can run
+ and expand them.
+ 
+ 
+ 
+ == New features in 10.10 ==
+ || '''New Feature'''|| '''Link to JIRA entries''' || '''Buddy tester''' || ''' Documentation
Available''' ||'''Comments''' ||
+ || JDBC 4.2 || [[https://issues.apache.org/jira/browse/DERBY-6000|DERBY-6000]] || Dag ||
[[https://issues.apache.org/jira/browse/DERBY-6070|DERBY-6070]]  || see below per JDBC class
||
+ 
+ === BatchUpdateException changes ===
+ 
+ Checked implementation and used debugger to test execution of creation and
+ use of getLargeUpdateCounts.
+ 
+ - ClientJDBCObjectFactoryImpl42#newBatchUpdateException ( String
+         message, String sqlState, int errorCode, long[] updateCounts,
+         !SqlException cause ): javadoc typo: "overriden"
+ 
+ - ditto in ClientJDBCObjectFactoryImpl#newBatchUpdateException (
+         String message, String sqlState, int errorCode, long[]
+         updateCounts, !SqlException cause )
+ 
+ - in Util#newBatchUpdateException,
+   in the java 8 branch, on exception we fall through to a Java 7 version.
+   Is this debugging code, or if not, why do you think we need it?
+ 
+ - is the necessary "degrade cascade" in
+   createJDBC42FactoryImplnecessary? Wouldn't a fail here indicate an
+   implementation issue? We know that Configuration.supportsJDBC42()
+   holds..
+ 
+ === CallableStatement changes ===
+ 
+ - In methods in !CallableStatement42 (and lower), why typically use the try block here,
as here:
+ 
+   public void setObject( int parameterIndex, java.lang.Object x, SQLType sqlType, int scaleOrLength
) throws !SQLException
+   {
+         try
+         {
+ 	  :
+  	  checkForClosedStatement();
+  	  setObject( parameterIndex, x, Utils42.getTypeAsInt(agent_, sqlType ), scaleOrLength
);
+         }
+         catch ( !SqlException se )  { throw se.get!SQLException(); }
+ 
+   The similar method in !PreparedStatement42 (they are redundantly
+   implemented since Java doesn't offer multiple inheritance the *42
+   variant already extend the *40 variants) uses the auxiliary method
+   "checkStatus" which wraps the "checkForClosedStatement" and throws
+   !SQLException if needed. In the above, "setObject" cannot throw
+   !SqlException anyway, and using "checkStatus" would make it simpler
+   and the implementations more obviously equal.
+ 
+ - Checked implementation and used debugger to test execution of creation and
+   use of !CallableStatement (4.2) and the new methods overloads of
+ 
+     - registerOutParameter (String parameterName, SQLType sqlType, String typeName)
+     - registerOutParameter (int parameterIndex, SQLType sqlType, String typeName)
+     
+ - but why do we need to implement this at all now that the interface has
+   a default method throwing SQLFeatureNotSupportedException? We do get
+   to check that the connection isn't closed...
+ 
+ - DERBY-6088, DERBY-6089.
+ 
+ === DatabaseMetaData ===
+ 
+ - Checked implementation and used debugger to test execution of
+   getIndexInfo, getMaxLogicalLobSize and supportsRefCursors.
+ 
+   Would it perhaps be more future proof (for mixed versions of client
+   server) to ask the server about maximal logical lob size?  Currently
+   it's hardwired to 0 in both drivers. For supportsRefCursors it seems
+   ok to hardwire since this would require implementation on both sides
+   I think.
+ 
+ (to be continued..)
+ 

Mime
View raw message