svn_log.txt

derby数据库源码。。。。。。。。。。。。。

------------------------------------------------------------------------
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 ([e-mail])

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 ([e-mail]).

------------------------------------------------------------------------
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 ([e-mail])
------------------------------------------------------------------------
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 GENERATED. The work of constructing these extra
   column values is done by genNewRCForInsert.
 - For columns which are GENERATED ALWAYS, we must make sure that
   the INSERT statement doesn't allow the user to insert their own value for
   the generated column.
 - The columns which are specified in the INSERT column spec may not match
   the order in which the columns arise in the table. Therefore, the column
   values may need to be re-ordered by the INSERT statement so that they
   occur in the proper order.
 - In the case when the ResultSet which provides the values for the INSERT
   statement is not just a single node, but is rather a tree of UnionNodes, the
   above processing needs to happen throughout the tree, not just at
   the root node. 

------------------------------------------------------------------------
r487314 | mamta | 2006-12-14 11:25:44 -0800 (Thu, 14 Dec 2006) | 10 lines

EmbedCallableStatement.executeStatement stuffs the output parameter value into
ParameterValueSet object. But ParameterValueSet object which is fetched at the
beginning of the method might not be the valid object if a new activation object
got created for the Statement because it was invalid. I am making changes such
that a fetch of ParameterValueSet object into a local variable is done after
the possiblity of new Activation object has been accounted for. I have also put
javadoc comments for the users of ParameterValueSet object which is returned
by EmbedPreparedStatement.getParms method.


------------------------------------------------------------------------
r487307 | djd | 2006-12-14 11:10:45 -0800 (Thu, 14 Dec 2006) | 3 lines

DERBY-2138 Remove the DataDictionaryContext and instead use the fact there is a single DataDictionary per database.
Cleanup DependableFinder to take a passed in reference to a data dictionary rather than trying to find the data
dictionary from the context.
------------------------------------------------------------------------
r486321 | myrnavl | 2006-12-12 13:22:50 -0800 (Tue, 12 Dec 2006) | 2 lines

DERBY-2143 - 1 more master/canon update

------------------------------------------------------------------------
r486240 | djd | 2006-12-12 09:09:19 -0800 (Tue, 12 Dec 2006) | 2 lines

DERBY-2138 (partial) Cleanup DependableFinder and associated classes by removing an unused method
and adding comments to related classes.
------------------------------------------------------------------------
r486201 | djd | 2006-12-12 07:59:52 -0800 (Tue, 12 Dec 2006) | 5 lines

DERBY-2040 (partial) Change the api for jarReader to return the StorageFile rather
than the (potentially) opened jar. Removes the possibility for user code to
access the jar by calling methods of JarReader directly (and hence abusing any
privileged blocks that would be required while opening the jar). Cleans up JarLoader
by having explict calls to open the stream or file within the class loader.
------------------------------------------------------------------------
r484841 | djd | 2006-12-08 15:23:46 -0800 (Fri, 08 Dec 2006) | 4 lines

DERBY-2138 (partial) Move the booting of the DataDictionary to BasicDatabase from LanguageConnectionFactory
wihc makes more sense once there is a single dictionary per database. Change some calls to obtain a reference
to the DataDictionary from Database instead of looking for the pushed DataDictionaryContext.
DataDictionaryContext context is still pushed, this is an incremental step to removing it.
------------------------------------------------------------------------
r484797 | suresht | 2006-12-08 13:42:14 -0800 (Fri, 08 Dec 2006) | 24 lines

DERBY-606 : SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE fails on (very) large tables

Patch Contributed by Mayuresh Nirhali.

Problem was when Allocated Extent associated with last allocated page is being
compressed, All the pages are found to be free, thus new_highest_page is set to
'-1'. Now, when the CompressSpaceOperation is being logged
CompressedNumber.writeInt method is called with value -1. This method is
written to throw exception if the value is less than Zero, hence the 
IOException occurs. 

This patch addresses the problem  by modifying compress 
log record to write the new Highest Page as an uncompressed number, 
if the database is created/hard-upgrade to 10.3. A new Compress Log 
Record Class is created that will read/write new_highest_page in compressed 
format as before 10.3. Old version of compress log Operation is used on 
recovery, if  the log record needs to be replayed on upgrade 
from old-version of the database and also on soft-upgrade to 10.3. 

Test cases for this bug are  added to the existing OnlineCompressTest.java
test and to the upgrade test .



------------------------------------------------------------------------
r484722 | djd | 2006-12-08 12:02:24 -0800 (Fri, 08 Dec 2006) | 4 lines

DERBY-538 DERBY-2040 Remove the FileResource.getAsStream method as the getAsFile()
method now returns a StorageFile and that class has a getInputStream method.
Incremental step in pushing the JarClassLoader to work off URLs for the jar files
and thus allow use of the standard java.net.URLClassLoader.
------------------------------------------------------------------------
r484672 | djd | 2006-12-08 09:51:55 -0800 (Fri, 08 Dec 2006) | 2 lines

DERBY-2083 Fix broken backup/restore tests. Caused by not updating path through code
when a service is directly accessed as a file rather than through the StorageFactory api.
------------------------------------------------------------------------
r484671 | myrnavl | 2006-12-08 09:48:02 -0800 (Fri, 08 Dec 2006) | 10 lines

DERBY-2143 - patch DERBY_2143_2110_trunk.diff2; 
  - adjusting the translated messages for changes of DERBY_2110
  - adjusting the translated messages for some removed messages that are
    still present in 10.2 (XJ089, XJ092, 01J03, 01J09, 01J11)