From derby-commits-return-10788-apmail-db-derby-commits-archive=db.apache.org@db.apache.org Mon Sep 08 16:02:14 2008 Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 99168 invoked from network); 8 Sep 2008 16:02:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Sep 2008 16:02:13 -0000 Received: (qmail 21898 invoked by uid 500); 8 Sep 2008 16:02:11 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 21876 invoked by uid 500); 8 Sep 2008 16:02:11 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 21867 invoked by uid 99); 8 Sep 2008 16:02:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Sep 2008 09:02:11 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Sep 2008 16:01:12 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 07B2B2388961; Mon, 8 Sep 2008 09:01:44 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r693144 - in /db/derby/site/trunk: build/site/releases/ src/documentation/content/xdocs/releases/ Date: Mon, 08 Sep 2008 16:01:43 -0000 To: derby-commits@db.apache.org From: rhillegas@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20080908160144.07B2B2388961@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: rhillegas Date: Mon Sep 8 09:01:42 2008 New Revision: 693144 URL: http://svn.apache.org/viewvc?rev=693144&view=rev Log: DERBY-3820: Second attempt to update the website. This fix removes the second table of contents from the 10.4.2.0 and 10.4.1.3 download pages. The links in those tables are dead. Modified: db/derby/site/trunk/build/site/releases/release-10.4.1.3.html db/derby/site/trunk/build/site/releases/release-10.4.2.0.html db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.1.3.html db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.2.0.html Modified: db/derby/site/trunk/build/site/releases/release-10.4.1.3.html URL: http://svn.apache.org/viewvc/db/derby/site/trunk/build/site/releases/release-10.4.1.3.html?rev=693144&r1=693143&r2=693144&view=diff ============================================================================== --- db/derby/site/trunk/build/site/releases/release-10.4.1.3.html (original) +++ db/derby/site/trunk/build/site/releases/release-10.4.1.3.html Mon Sep 8 09:01:42 2008 @@ -482,24 +482,7 @@

Release Notes for Derby 10.4.1.3

These notes describe the difference between Derby release 10.4.1.3 and the preceding release 10.3.2.1.

- - +

Overview

Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs.

Derby functionality includes:

@@ -509,7 +492,7 @@
  • Network client JDBC drivers
  • Command line tools: ij (SQL scripting), dblook (schema dump) and sysinfo (system info)
    • - +

    New Features

    This is a feature release. The following new features were added:

      @@ -524,7 +507,7 @@
    • Caching of the isolation level and the current schema in the client driver.
    • Implement a new multi-threaded buffer manager to get better scalability on machines with multiple CPUs or multiple cores.
    - +

    Bug Fixes

    The following issues are addressed by Derby release 10.4.1.3. These issues are not addressed in the preceding 10.3.2.1 release.

    @@ -745,7 +728,7 @@
    DERBY-1573Unsafe synchronization in NetworkServerControlImpl
    - +

    Issues

    Compared with the previous release (10.3.2.1), Derby release 10.4.1.3 introduces the following new features and incompatibilities. These merit your special attention.

      @@ -779,12 +762,12 @@
    - +

    Note for DERBY-3585

    - +
    Summary of Change

    Shutting down the Network Server now supports user authentication, and in fact requires credentials when authentication is enabled.

    - +
    Symptoms Seen by Applications Affected by Change

    Previously, a network server running with user authentication didn't check for user credentials for server shutdown. Any client could shut down the server by calling NetworkServerControl with a shutdown command-line argument or by invoking the shutdown() method (provided the shutdown was initiated on the host running the server). While this generated a console warning (Connection refused : Invalid authentication.), the server shutdown proceeded and could also result in open databases not being properly closed.

    Now, class NetworkServerControl supports user and password information as command-line and constructor arguments. When running a network server with user authentication, a server shutdown now requires user credentials; if the user authentication check fails, the client sees an authentication error and the running server remains intact. Note that Derby does not yet restrict the shutdown privilege to specific users: the server can be shut down by any user on the server machine who presents valid credentials.

    @@ -799,7 +782,7 @@

    - +
    Incompatibilities with Previous Release

    If running a network server without user authentication (the default) no command-line or API incompatibilities will be experienced.

    However, some incompatibilities were introduced if running a network server with user authentication:

    @@ -816,90 +799,90 @@

    - +
    Rationale for Change

    The previous behavior represented a security issue, because any client could shut down a network server running with user authentication from the same host without needing to provide user credentials.

    - +
    Application Changes Required

    Application code and scripts will need to be adjusted to provide user credentials for shutting down a network server that runs with user authentication.

    - +

    Note for DERBY-3460

    - +
    Summary of Change

    The two following reserved keywords are introduced: NONE and CURRENT_ROLE.

    - +
    Symptoms Seen by Applications Affected by Change
    - +
    Incompatibilities with Previous Release
    - +
    Rationale for Change
    - +
    Application Changes Required
    - +

    Note for DERBY-3301

    - +
    Summary of Change

    Queries with nested EXIST, ANY or IN clauses now return correct results.

    - +
    Symptoms Seen by Applications Affected by Change

    In the previous release, applications that executed SQL statements containing nested EXISTS, ANY or IN clauses could see fewer rows than those satisfying the query. In particular, rows that had the same value for one of the selected columns as another row might not have been returned.

    - +
    Incompatibilities with Previous Release

    None.

    - +
    Rationale for Change

    The previous behavior violated the ANSI SQL standard. The new behavior is correct.

    - +
    Application Changes Required

    Typically none, but applications must handle that the correct results are now returned.

    - +

    Note for DERBY-3026

    - +
    Summary of Change

    The frameworks directory (and its contents) has been removed.

    - +
    Symptoms Seen by Applications Affected by Change

    -frameworks +frameworks
    Incompatibilities with Previous Release

    Applications or commands referencing files in the frameworks directory will fail.

    - +
    Rationale for Change

    In the 10.2.1.6 release, new and improved scripts were added in a new bin directory, intended to replace the scripts in the frameworks directory. The new scripts follow Apache conventions, and all scripts are located in a single directory, making them easier to find. Removing the old and deprecated scripts and the frameworks directory itself will eliminate a potential source of confusion and annoyance among users.

    The frameworks directory has been deprecated since the 10.2.1.6 release, and has not been maintained since then. The 10.2.1.6 release notes announced the deprecation of the scripts in the frameworks directory, and an additional file (frameworks.DEPRECATED.txt) was added in the top-level directory of the 10.3.1.4 release, with the purpose of alerting users about this change. A warning message was also added to the scripts in the frameworks directory at the same time.

    - +
    Application Changes Required

    All references to the frameworks directory or its contents must be updated. The scripts in the bin directory may be used instead of the old scripts.

    - +

    Note for DERBY-3013

    - +
    Summary of Change

    The column default value can now also be specified as CURRENT_USER or SESSION_USER.

    - +
    Symptoms Seen by Applications Affected by Change

    None

    - +
    Incompatibilities with Previous Release

    None

    - +
    Rationale for Change

    Extend Derby's support for standard SQL constructions.

    - +
    Application Changes Required

    None.

    - +

    Note for DERBY-2351

    - +
    Summary of Change

    An ORDER BY clause of a DISTINCT query which specifies to order by a column which was not in the DISTINCT list is now rejected, because the intent of the query is ambiguous. Previously, Derby instead produced non-distinct results. Also, an ORDER BY clause which specifies a table-name-qualified column alias is now rejected as invalid, where previously it was accepted.

    - +
    Symptoms Seen by Applications Affected by Change
    - +
    New rules for DISTINCT and ORDER BY

    Applications which specify certain combinations of SELECT DISTINCT with ORDER BY will now receive an error message, whereas formerly such applications received non-distinct results.

    As an example, take the following:

    @@ -908,7 +891,7 @@

    The query above is now rejected, with the error message:

    If the AGE column is included in the DISTINCT list in the above query, there is no ambiguity

    - +
    New column alias rules

    Applications which specify a column alias for a column in the SELECT statement, and which specify an ORDER BY clause which specifies that column alias qualified by the table name, will now receive an error indicating that the ORDER BY clause is invalid.

    As an example, take the following:

    @@ -918,7 +901,7 @@

    select t1.id as idcolumn1, t1.id as idcolumn2 from t1 order by idcolumn1, idcolumn2;

    or

    select t1.id as idcolumn1, t1.id as idcolumn2 from t1 order by t1.id, t1.id;

    - +
    Rationale for Change

    When the query ambiguously specifies both DISTINCT and ORDER BY, Derby was unsure whether to return the rows properly ordered, but non-distinct, or to return a distinct set of rows, but in an unknown order. Since no clear resolution of the ambiguity could be found, we chose instead to reject the query.

    The rules for resolving column references in ORDER BY clauses have been enhanced to consider column aliases and column names more fully. Derby now uses different resolution rules depending on whether the ORDER BY column reference is table.column, or just column:

    @@ -928,29 +911,29 @@

    - +
    Application Changes Required

    A query which specifies ordering by a non-distinct column should instead include the ORDER BY column in the DISTINCT list, to resolve the ambiguity about which values of that column should be used to distinctly identify the resulting rows.

    A query which specifies table-name.alias-name should be rewritten to specify either simply alias-name, or table-name.column-name.

    - +

    Note for DERBY-2065

    - +
    Summary of Change

    Error code changed for embedded connection when a connection with an open transaction is attempted closed.

    - +
    Symptoms Seen by Applications Affected by Change

    In the previous release, calling Connection.close() on a connection with an open transaction raised an error with error code 25001 with the client driver, whereas the embedded driver raised error code 25000. The embedded driver has now been changed to raise the same error code as the client driver, i.e. 25001, as specified by the SQL standard.

    - +
    Incompatibilities with Previous Release

    Embedded applications that are dependent on the error code ever being "25000" could start failing. Embedded applications that are dependent on the error code never being "25001" could start failing.

    - +
    Rationale for Change

    Harmonize error codes raised by the client and embedded drivers, thereby also making the embedded driver compatible with the SQL standard.

    - +
    Application Changes Required

    Applications that are dependent on the error code must be changed to expect the new code.

    - +

    Build Environment

    Derby release 10.4.1.3 was built using the following environment:

      @@ -972,7 +955,7 @@ JSR 169 - J2ME support was built using java.sun.com/j2me (cdc-1_1-fr-ri, jdbc_cdc1.0).
    - +

    Verifying releases

    It is essential that you verify the integrity of the downloaded files using the PGP and MD5 signatures. MD5 verification ensures the file was not corrupted during the download process. PGP verification ensures that the file came from a certain person.

    Modified: db/derby/site/trunk/build/site/releases/release-10.4.2.0.html URL: http://svn.apache.org/viewvc/db/derby/site/trunk/build/site/releases/release-10.4.2.0.html?rev=693144&r1=693143&r2=693144&view=diff ============================================================================== --- db/derby/site/trunk/build/site/releases/release-10.4.2.0.html (original) +++ db/derby/site/trunk/build/site/releases/release-10.4.2.0.html Mon Sep 8 09:01:42 2008 @@ -477,24 +477,7 @@

    Release Notes for Derby 10.4.2.0

    These notes describe the difference between Derby release 10.4.2.0 and the preceding release 10.4.1.3.

    - - +

    Overview

    Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs.

    Derby functionality includes:

    @@ -504,10 +487,10 @@
  • Network client JDBC drivers
  • Command line tools: ij (SQL scripting), dblook (schema dump), and sysinfo (system info)
    • - +

    New Features

    This is a maintenance release. No new features were added.

    - +

    Bug Fixes

    The following issues are addressed by Derby release 10.4.2.0. These issues are not addressed in the preceding 10.4.1.3 release.

    @@ -725,7 +708,7 @@
    DERBY-48A connection request that has a default schema that is being created by another transaction will fail to connect
    - +

    Issues

    Compared with the previous release (10.4.1.3), Derby release 10.4.2.0 introduces the following new features and incompatibilities. These merit your special attention.

      @@ -739,46 +722,46 @@
    - +

    Note for DERBY-3701

    - +
    Summary of Change

    An error message will be logged to derby.log if the Network Server tracing file cannot be created. Starting with version 10.5, the Network Server will attempt to create the trace directory if it does not exist. Any intervening directories in the given path will also be created if possible.

    - +
    Symptoms Seen by Applications Affected by Change

    Before the fix for DERBY-3110, if derby.drda.traceAll was set to true and the derby.drda.traceDirectory was set to a non-existent directory, no tracing would occur and no error would occur. After the fix for DERBY-3110, an error "java.lang.Exception: DRDA_UnableToAccept.S:Unable to accept connections" would occur and the client would hang and no tracing would occur. With this fix for version 10.5 and higher, the Network Server will attempt to create the trace directory if possible. For 10.4.2 (and the next release on the 10.3 branch), the Network Server will still not try to create the directory. For all these releases the Network Server will print an error on session connect if there is any problem creating the trace file, but the Network Server will not cause the session connection to fail. Users who have trace turned on and the trace directory set to a non-existent directory may now see exceptions in the derby.log on connect indicating that the trace file is not found or with 10.5 or higher they may see tracing occur where it did not before.

    - +
    Incompatibilities with Previous Release

    Tracing properties will not be ignored or cause the client to hang if the trace directory is set to a non-existent directory.

    - +
    Rationale for Change

    The tracing properties should not be summarily ignored or cause the client to hang if the trace directory does not exist.

    - +
    Application Changes Required

    Applications that counted on the derby.drda.traceAll property being ignored if derby.drda.traceDirectory was set to a non-existent directory, need to turn tracing off or they may now see many errors in the derby.log or large amounts of tracing.

    - +

    Note for DERBY-48

    - +
    Summary of Change

    In Derby, a user's initial default schema is named the same as the user name, or APP if a user is not provided at connect time. This schema is implicitly auto-created the first time a schema object is created in that schema.

    Previously, this auto-creation would be performed as part of the user transaction. This would sometimes lead to locking issues as described in this issue. With this change, the auto-creation is now performed and committed immediately in a separate sub-transaction.

    - +
    Symptoms Seen by Applications Affected by Change

    The initial default schema will be present in cases where it previously would not yet have been created: If the user transaction that creates a schema object leading to auto-creation of the initial default schema rolls back for some reason after having created the schema, up till now the auto-creation of the initial default schema would be rolled back as well. Since it is now created and committed in a sub-transaction, the schema creation will not be rolled back: the default schema will persist.

    - +
    Incompatibilities with Previous Release

    Most applications should not be impacted by this change, but there are some corner cases as described below:

    If the application tests for the existence of the initial default schema by querying Derby system tables, the results could now be different than in earlier releases, if the test is made after a rollback as described in the previous section.

    Since the initial default schema will now potentially exist in cases where it would previously not exist, schema operations may be impacted, e.g. where before a DROP SCHEMA <default schema name> RESTRICT would fail due to it not yet existing, it could now work (if empty), depending on when the drop attempt is made.

    - +
    Rationale for Change

    Implicit schema creation is now performed in its own transaction to avoid deadlocks with other connections accessing the same schema.

    Doing this is a separate transaction avoids holding dictionary locks longer than necessary, cf. DERBY-48 and thus reduces the chance for deadlocks.

    - +
    Application Changes Required

    Verify that the application code does not rely on the initial default schema being absent after a rollback.

    - +

    Build Environment

    Derby release 10.4.2.0 was built using the following environment:

      @@ -800,7 +783,7 @@ JSR 169 - J2ME libraries were supplied by phoneme.dev.java.net (CDC, Foundation Profile, and Personal Basis Profile meeting the 1.1.2 specifications). JSR169 libraries were supplied by java.sun.com.
    - +

    Verifying releases

    It is essential that you verify the integrity of the downloaded files using the PGP and MD5 signatures. MD5 verification ensures the file was not corrupted during the download process. PGP verification ensures that the file came from a certain person.

    Modified: db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.1.3.html URL: http://svn.apache.org/viewvc/db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.1.3.html?rev=693144&r1=693143&r2=693144&view=diff ============================================================================== --- db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.1.3.html (original) +++ db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.1.3.html Mon Sep 8 09:01:42 2008 @@ -57,23 +57,6 @@

    These notes describe the difference between Derby release 10.4.1.3 and the preceding release 10.3.2.1.

    -

    Overview

    Modified: db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.2.0.html URL: http://svn.apache.org/viewvc/db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.2.0.html?rev=693144&r1=693143&r2=693144&view=diff ============================================================================== --- db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.2.0.html (original) +++ db/derby/site/trunk/src/documentation/content/xdocs/releases/release-10.4.2.0.html Mon Sep 8 09:01:42 2008 @@ -78,28 +78,9 @@

    These notes describe the difference between Derby release 10.4.2.0 and the preceding release 10.4.1.3.

    -

    Overview

    - -

    Derby is a pure Java relational database engine using standard SQL and JDBC as its APIs.