Differences between revisions 14 and 15
Revision 14 as of 2013-03-21 04:26:15
Size: 8408
Editor: DagWanvik
Comment:
Revision 15 as of 2013-03-21 04:28:31
Size: 8440
Editor: DagWanvik
Comment:
Deletions are marked like this. Additions are marked like this.
Line 132: Line 132:
* * Currently, our docs say:
Line 137: Line 137:
}}}
Line 139: Line 139:
{{{

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.

Please add more chapters for each new feature buddy tested.

New feature in 10.10

New Feature

Link to JIRA entries

Buddy tester

Documentation Available

Comments

JDBC 4.2

DERBY-6000

Dag

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

Driver

- According to the new Javadoc, #acceptsURL and #connect should throw !SQLException on null URL: Both EmbeddedDriver and ClientDriver throw NullPointerException instead.

JDBCType

In PreparedStatementTest, the array ILLEGAL_JDBC_TYPES seems to miss some types we do not support (from the types in JDBCType):

  • BIT
  • DISTINCT
  • LONGNVARCHAR
  • NULL
  • OTHER

Should these be added to make sure we react properly if these are attempted used? (NULL is a value, not a type, but still defined in JDBCType..)

ResultSet

I would like to see negative tests for the new overloads of updateObjects too, with respect to the targetSqlType.

SQLTimeoutException

The javadoc here now specifies that this should be throw if the value given by DriverManager.setLoginTimeout is exceeded. I can't find a test for this (see my comment on DERBY-2026); and I also could not find any code on the client that catches a timeout on the login connection socket to convert an SocketTimeoutException to this error.

See also DERBY-6094 Derby ignores DriverManager.setLoginTimeout().

Buddy testing completed 2013-02-27 dag

New feature in 10.10

New Feature

Link to JIRA entries

Buddy tester

Documentation Available

Comments

UDA

DERBY-672

Dag

DERBY-5926

see below

Buddy testing/review of user defined aggregates feature

* Currently, our docs say:

  "An unqualified UDA name may not be the name of an aggregate defined in part 2 of the SQL Standard, section 10.9:

  ANY..
  • But even when name is qualified, I see:

  ij> create derby aggregate app.ANY for int returns int external name 'foo.Agg';
  ERROR 42X01: Syntax error: Encountered "ANY" at line 1, column 28.
  • I need to quote it:

  ij> create derby aggregate app."ANY" for int returns int external name 'foo.Agg';
  0 rows inserted/updated/deleted
  • Code or doc correct?

*

  "In general, UDAs live in the same namespace as one-argument user-defined functions (see CREATE FUNCTION statement)."
  • But ij doesn't show aggregates:

  ij> create function app."ANY" (i int) returns int parameter style java language java external name 'foo.bar';

  ERROR X0Y87: There is already an aggregate or function with one argument whose name is 'APP'.'ANY'.

  ij> show functions in app;
  FUNCTION_SCHEM|FUNCTION_NAME               |REMARKS                            
  -------------------------------------------------------------------------------
  0 rows selected

* checked simple int aggregator: found agg class could not be static nested class in another(?)

  • Expected or pilot error? If expected, why? document? Currently we say:

  "The !ClassNameString is a single-quoted string. It is the full name of a Java class which implements the org.apache.derby.agg.Aggregator interface."

* checked USAGE privilege +/- via both user and role privilege grants: OK

* The merge method wasn't used in my simple example. When is it used?

  • If only needed in compex queries, we might want to warn the user on how to construct test cases to debug it...

* In the GRANT-statement refman page, we are inconsisten when it comes to explaining

  • identifiers (seen when looking at GRANT USAGE of aggregates): "table-Name" occurences are linked to a section explainig them (rreftablename.html), but UDA names are defined in-lined as

      GRANT USAGE ON DERBY AGGREGATE [ schemaName. ] SQL92Identifier TO grantees
  • In a third variant,

      GRANT EXECUTE ON { FUNCTION | PROCEDURE } routine-designator TO grantees
  • routine-designator is defined locally as

      routine-designator { function-name | procedure-name }  
  • without links to what "function-name" or "procedure-name" might look like. It would be good to harmonize the latter two forms to a central definition as for "table-Name".

    Finally, I noted that the definition page for SchemaName doesn't link to the SQL92Identifier page...

TenTenOneBuddyTesting (last edited 2013-03-21 04:28:31 by DagWanvik)