官网原版jdk1.6.0_45（linux）

------------------------------------------------------------------------ r491786 | kahatlen | 2007-01-02 04:47:47 -0800 (Tue, 02 Jan 2007) | 9 lines DERBY-2200: Add performance tests to Derby using the junit perf framework This patch (derby2200.p1.diff.txt) adds -- few simple performance tests using the junit perf framework. -- small addition to the reporting in JDBCPerfTestCase to indicate the framework the test is running in. Patch contributed by Sunitha Kambhampati. ------------------------------------------------------------------------ r491769 | kahatlen | 2007-01-02 02:16:53 -0800 (Tue, 02 Jan 2007) | 2 lines DERBY-2149: Replace Vectors and Hashtables with ArrayLists and HashMaps in RAMTransaction ------------------------------------------------------------------------ r491768 | kahatlen | 2007-01-02 02:13:27 -0800 (Tue, 02 Jan 2007) | 4 lines DERBY-2100: Convert derbynet/prepStmt.java to JUnit Patch contributed by ?\195?\152ystein Gr?\195?\184vlen. ------------------------------------------------------------------------ r491632 | bpendleton | 2007-01-01 13:10:20 -0800 (Mon, 01 Jan 2007) | 12 lines DERBY-2202: DROP PROCEDURE depends on SET SCHEMA This patch was contributed by Yip Ng (yipng168@gmail.com) The symptom of this jira is the same as those described in DERBY-1304 for DROP VIEW except that it applies to DROP PROCEDURE, DROP FUNCTION and DROP SYNONYM statements. (Their bind logic are centralized in DropAliasNode.) The DropAliasNode's bindStatement() should have created a dependency on the statement, so when its associated alias descriptor gets dropped, the statement can be invalidated accordingly. This explains why subsequent DROP PROCEDURE statement fails. ------------------------------------------------------------------------ r489603 | kahatlen | 2006-12-22 02:25:22 -0800 (Fri, 22 Dec 2006) | 2 lines DERBY-2199: Use initCause() in BaseJDBCTestCase.assertSQLState(). ------------------------------------------------------------------------ r489597 | kahatlen | 2006-12-22 02:10:10 -0800 (Fri, 22 Dec 2006) | 5 lines DERBY-2152: Support diagnostic vti tables that take parameters, such as SpaceTable Fix test failures in jdk6. Patch contributed by A B (qozinx@gmail.com). ------------------------------------------------------------------------ r489053 | kahatlen | 2006-12-20 03:28:07 -0800 (Wed, 20 Dec 2006) | 3 lines DERBY-2191: Cleanup of FormatableBitSet Removal of dead code. Patch contributed by Dyre Tjeldvoll. ------------------------------------------------------------------------ r488834 | abrown | 2006-12-19 14:29:22 -0800 (Tue, 19 Dec 2006) | 3 lines Remove unnecessary imports from NewInvocationNode.java that were added as part of svn #488827. ------------------------------------------------------------------------ r488827 | abrown | 2006-12-19 14:10:56 -0800 (Tue, 19 Dec 2006) | 21 lines DERBY-2152: Support diagnostic "table functions" for querying Derby diagnostic VTIs that take parameters. The table functions are exposed via the TABLE constructor syntax: SELECT <rcList> from TABLE ( <sysdiag-schema>.<vti-table-name> (<arg-list>) ) [ AS ] corrlationName Note that: a. We only support VTI table function names that are in the SYSCS_DIAG schema b. The correlation name *is* required, though use of the "AS" keyword is optional (section 7.6 of the SQL 2003 spec, "<table primary>"). c. The argument list can be empty if the underlying VTI supports it. The VTI table names that have been added are as follows: SYSCS_DIAG.SPACE_TABLE maps to org.apache.derby.diag.SpaceTable SYSCS_DIAG.ERROR_LOG_READER maps to org.apache.derby.diag.ErrorLogReader SYSCS_DIAG.STATEMENT_DURATION maps to org.apache.derby.diag.StatementDuration ------------------------------------------------------------------------ r488803 | rhillegas | 2006-12-19 12:45:20 -0800 (Tue, 19 Dec 2006) | 1 line DERBY-2129: Record release of 10.2.2.0 in the STATUS file. ------------------------------------------------------------------------ r488672 | bernt | 2006-12-19 05:35:14 -0800 (Tue, 19 Dec 2006) | 1 line DERBY-2147 Enable code that allows pattern and escape in LIKE predicate to be column references ------------------------------------------------------------------------ r487788 | tmnk | 2006-12-16 03:16:04 -0800 (Sat, 16 Dec 2006) | 1 line - DERBY-1471 Implement layer B streaming for new methods defined in JDBC4.0 - Patch by Tomohito Nakayama (tomonaka@basil.ocn.ne.jp) ------------------------------------------------------------------------ r487742 | djd | 2006-12-15 16:54:35 -0800 (Fri, 15 Dec 2006) | 2 lines DERBY-2164 Add some comments to EngineType class and clean up its use. ------------------------------------------------------------------------ r487656 | bpendleton | 2006-12-15 12:44:53 -0800 (Fri, 15 Dec 2006) | 1 line Correct typo in checkForAutoIncrement javadoc ------------------------------------------------------------------------ r487655 | djd | 2006-12-15 12:37:52 -0800 (Fri, 15 Dec 2006) | 3 lines DERBY-2179 Temp fix to the test to avoid installing a thread context class loader and losing the previously installed one. Can be omitted beacuse the actual portion of the test fixture that uses the class loader is blocked by DERBY-2162. ------------------------------------------------------------------------ r487414 | bpendleton | 2006-12-14 17:01:14 -0800 (Thu, 14 Dec 2006) | 55 lines DERBY-1644: NPE when inserting values to tbl w/ identity col gen by default When the VALUES clause encounters multiple rows, it generates a UNION node tree to combine the rows to be inserted. InsertNode notices the top-level UNION node and calls the special checkAutoincrementUnion() method which knows how to recursively traverse the Union tree and call checkAutoIncrement() on the underlying RowResultSetNode instances at the leaf level of the tree. HOWEVER, when the number of columns in the rows in the VALUES clause is a subset of the number of columns in the table we're inserting into, the top node of the tree is not a UnionNode, but is rather a ProjectRestrictNode. This means that we skip past the UnionNode test and just call checkAutoincrement(), which processes the PRN but doesn't go down to the RowResultSetNode(s) at the leaf level. This leaves the ResultColumn instance at the leaf level with a NULL column descriptor, which causes the NPE during the code generation phase. And, there is a second, related problem. The enhanceRCLForInsert() call is also only made at the top level of the tree. However, this call is a necessary pre-condition for calling checkAutoincrement() because enhanceRCLForInsert() ensures that the proper ResultColumnList values are in place prior to the checkAutoincrement() reconciliation of the column lists. The patch solves these problems by merging the code from InsertNode.bind together with the current recursive processing in ResultColumnList.checkAutoincrementUnion() to produce a new recursive routine, which I have called enhanceAndCheckForAutoincrement(), which will recursively traverse the ResultSet tree, calling *both* enhanceRCLForInsert() and checkAutoincrement() on the various nodes in the tree. Thus the primary ideas involved in this patch are: - When an INSERT statement will insert multiple rows from the VALUES clause, the compiler will compile the various values into a tree of UnionNodes with RowResultSetNodes at the leaves of the three - The columns specified in the INSERT statement may be a subset of the rows in the table. The "extra" columns need to be constructed by the INSERT statement, either by generating NULL values for those columns which are nullable, or by compiling a default values for those columns which have DEFAULT values, or by generating a value for an IDENTITY column which is GENERAT