You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by rh...@apache.org on 2006/12/18 18:34:40 UTC
svn commit: r488358 - /db/derby/code/branches/10.2/RELEASE-NOTES.html
Author: rhillegas
Date: Mon Dec 18 09:34:39 2006
New Revision: 488358
URL: http://svn.apache.org/viewvc?view=rev&rev=488358
Log:
DERBY-2171: Rework Issues section of 10.2 Relese Notes.
Modified:
db/derby/code/branches/10.2/RELEASE-NOTES.html
Modified: db/derby/code/branches/10.2/RELEASE-NOTES.html
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.2/RELEASE-NOTES.html?view=diff&rev=488358&r1=488357&r2=488358
==============================================================================
--- db/derby/code/branches/10.2/RELEASE-NOTES.html (original)
+++ db/derby/code/branches/10.2/RELEASE-NOTES.html Mon Dec 18 09:34:39 2006
@@ -195,25 +195,38 @@
<h2><a name="Issues"></a>Issues</h2>
<p>
-10.2.2.0 does not introduce any additional issues beyond the 10.2.1.6 issues.
- Those issues are:
+Applications which run against Derby 10.0 or 10.1 may rely on
+ incorrect Derby behavior. After upgrading to 10.2, those
+ applications may need some recoding so that they no longer rely
+ on bad behavior which has been fixed. Please consult the
+ following list of issues which may require some application recoding.
+Note that 10.2.2.0 does not introduce any additional issues beyond the
+ issues introduced by 10.2.1.6:
</p>
<ul>
-<li><a href="#253">253</a> - Client should throw not implemented exception for depricated setUnicodeStream/getUnicodeStream</li>
-<li><a href="#668">668</a> - SysInfo does not print the right information when Derby is not loaded through the classpath.</li>
-<li><a href="#721">721</a> - State of InputStream retrieved from resultset is not clean , if there exists previous InputStream .</li>
-<li><a href="#781">781</a> - Materialize subqueries in select list where possible to avoid creating invariant resultsets many times.</li>
-<li><a href="#822">822</a> - Client driver: Pre-fetch data on executeQuery()</li>
-<li><a href="#1130">1130</a> - Client should not allow databaseName to be set with setConnectionAttributes</li>
-<li><a href="#1295">1295</a> - Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode</li>
-<li><a href="#1314">1314</a> - Differences between client and embedded when invoking stored procedures using Statement.executeUpdate()</li>
-<li><a href="#1323">1323</a> - Detectability methods rowUpdated, rowInserted, rowDeleted can be called from illegal states in both clients</li>
-<li><a href="#1357">1357</a> - Short-circuit logic in optimizer appears to be incorrect...</li>
-<li><a href="#1384">1384</a> - Increase default BLOB/CLOB length to maximum supported (2G?)</li>
-<li><a href="#1621">1621</a> - Trigger action statement is not recompile when there is a change that would affect it.</li>
-<li><a href="#1652">1652</a> - Update trigger updating the same rows as the original update does not throw an exception ERROR 54038: "Maximum depth of nested triggers was exceeded" as it should</li>
-<li><a href="#1867">1867</a> - Document algorithm support required for using secmec 8(USRSSSBPWD) and limitation on ibm141 vm.</li>
+<li><a href="#253">Note for DERBY-253</a> - PreparedStatement.setUnicodeStream() and ResultSet.getUnicodeStream()
+throw SQLException when invoked after upgrading to Apache Derby 10.2.</li>
+<li><a href="#668">Note for DERBY-668</a> - Sysinfo needs special permissions when run under a Java security manager.</li>
+<li><a href="#721">Note for DERBY-721</a> - Behavior has changed for applications which open two InputStreams on the
+ same ResultSet column.</li>
+<li><a href="#781">Note for DERBY-781</a> - Compilation times may increase for queries which have subqueries in
+ the FROM clause.</li>
+<li><a href="#822">Note for DERBY-822</a> - Queries may fail earlier and locks may be acquired earlier when
+executing queries.</li>
+<li><a href="#1130">Note for DERBY-1130</a> - When using Derby's client DataSources, you can no longer set the database name using
+ setConnectionAttributes().</li>
+<li><a href="#1295">Note for DERBY-1295</a> - Result sets of type TYPE_SCROLL_INSENSITIVE no longer implicitly close
+when positioned at the end in autocommit mode.</li>
+<li><a href="#1314">Note for DERBY-1314</a> - The return values of executeQuery() and executeUpdate() have changed
+ for the Derby network client.</li>
+<li><a href="#1323">Note for DERBY-1323</a> - Calls to rowUpdated(), rowDeleted(), and rowInserted() now forbidden
+on unpositioned, forward-only ResultSets.</li>
+<li><a href="#1357">Note for DERBY-1357</a> - Performance may change for queries with nested subqueries and/or large
+ FROM clauses.</li>
+<li><a href="#1384">Note for DERBY-1384</a> - Maximum BLOB/CLOB length has increased to 2G-1.</li>
+<li><a href="#1652">Note for DERBY-1652</a> - Recursive trigger firing disallowed.</li>
+<li><a href="#1867">Note for DERBY-1867</a> - With IBM 1.4.1 JVM, trying to connect to the server using the derby client with security mechanism 8 (USRSSSBPWD) will result in error.</li>
</ul>
<hr/>
@@ -272,21 +285,21 @@
</h3>
<h4>Problem</h4>
<p>
-Sysinfo classpath information was insufficiently detailed.
+Sysinfo needs special permissions when run under a Java security manager.
</p>
</blockquote>
<blockquote>
<h4>Symptoms</h4>
<p>
-Sometimes it was hard to tell where the Derby classes were actually being loaded from in the JVM.
+If you do not provide these permissions, you will see a message such as the following in your sysinfo output: Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read).
</p>
</blockquote>
<blockquote>
<h4>Cause</h4>
<p>
-The algorithm that sysinfo used for analyzing and reporting on the application classpath was not robust.
+Such a message does not indicate an error; it simply means that the sysinfo tool was unable to provide detailed classpath information because it did not have permission to read the classpath. In prior releases, under these circumstances, sysinfo would silently print nothing, now it prints an informational message about the reason that it couldn't provide any classpath information.
</p>
</blockquote>
@@ -307,7 +320,8 @@
<blockquote>
<h4>Workaround</h4>
<p>
-No workaround. The behavior is now correct.
+Grant these permissions so that sysinfo can run correctly under the
+ Java security manager.
</p>
</blockquote>
@@ -317,16 +331,20 @@
<a name="721"></a>
<a href="http://issues.apache.org/jira/browse/DERBY-721">DERBY-721</a>
</h3>
+</blockquote>
+<blockquote>
<h4>Problem</h4>
<p>
-Undefined results were returned to an application which
-opend an InputStream twice on the same column of a ResultSet.
+Behavior has changed for applications which open two InputStreams on the
+ same ResultSet column.
</p>
</blockquote>
<blockquote>
<h4>Symptoms</h4>
<p>
+Undefined results were returned to an application which
+opened an InputStream twice on the same column of a ResultSet.
The value siphoned out of the column was erratic.
</p>
</blockquote>
@@ -363,7 +381,8 @@
</h3>
<h4>Problem</h4>
<p>
-When optimizing a query that has one or more non-flattenable subqueries in the FROM clause, Derby will now check to see if it is possible to perform a hash join with that subquery as the inner table. Prior to Derby 10.2, the optimizer would never consider a hash join with a subquery; it only did nested loop joins.
+Compilation times may increase for queries which have subqueries in
+ the FROM clause.
</p>
</blockquote>
@@ -397,7 +416,8 @@
<blockquote>
<h4>Workaround</h4>
<p>
-There is no way to disable/workaround this new behavior since the symptom as described above is a good one for Derby.
+There is no way to disable/workaround this new behavior. The increased
+ compilation time buys better performance at query execution time.
</p>
<p>
That said, any user who notices a negative performance change after
@@ -463,8 +483,18 @@
<a name="1130"></a>
<a href="http://issues.apache.org/jira/browse/DERBY-1130">DERBY-1130</a>
</h3>
+</blockquote>
+<blockquote>
<h4>Problem</h4>
<p>
+When using Derby's client DataSources, you can no longer set the database name using
+ setConnectionAttributes().
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
Derby's client DataSources were using a wrong database name when
getting a connection in the following case:
</p>
@@ -477,15 +507,9 @@
</blockquote>
<blockquote>
-<h4>Symptoms</h4>
-<p>
-Instead of throwing an exception saying databaseName is a required Derby DataSource property and must be set, client driver was using "null" as database name and returning a connection to database named "null".
-</p>
-</blockquote>
-
-<blockquote>
<h4>Cause</h4>
<p>
+Instead of throwing an exception saying databaseName is a required Derby DataSource property and must be set, client driver was using "null" as database name and returning a connection to database named "null".
The database name was constructed wrongly in the client driver.
</p>
</blockquote>
@@ -500,7 +524,8 @@
<blockquote>
<h4>Workaround</h4>
<p>
-If using release prior to version 10.2, make sure database name is set
+When upgrading an application to run against Derby 10.2, make sure the
+ database name is set
only as a DataSource property when using Derby's client DataSources.
</p>
</blockquote>
@@ -513,7 +538,7 @@
</h3>
<h4>Problem</h4>
<p>
-Result sets of type TYPE_SCROLL_INSENSITIVE used to implicitly close
+Result sets of type TYPE_SCROLL_INSENSITIVE no longer implicitly close
when positioned at the end in autocommit mode.
</p>
</ul>
@@ -561,16 +586,21 @@
<a name="1314"></a>
<a href="http://issues.apache.org/jira/browse/DERBY-1314">DERBY-1314</a>
</h3>
+</blockquote>
+<blockquote>
<h4>Problem</h4>
<p>
-The behaviour of executeQuery() and executeUpdate() did not match the
-JDBC specification when invoking stored procedures.
+The return values of executeQuery() and executeUpdate() have changed
+ for the Derby network client.
</p>
-</ul>
</blockquote>
<blockquote>
<h4>Symptoms</h4>
+<p>
+The behaviour of executeQuery() and executeUpdate() did not match the
+JDBC specification when invoking stored procedures.
+</p>
<ul>
<li> When invoking a stored procedure with executeQuery() or
executeUpdate(), an exception was thrown indicating that the
@@ -615,17 +645,24 @@
</blockquote>
-WORKAROUND
-
-None.
<hr/>
<blockquote>
<h3>
<a name="1323"></a>
<a href="http://issues.apache.org/jira/browse/DERBY-1323">DERBY-1323</a>
</h3>
+</blockquote>
+<blockquote>
<h4>Problem</h4>
<p>
+Calls to rowUpdated(), rowDeleted(), and rowInserted() now forbidden
+on unpositioned, forward-only ResultSets.
+</p>
+</blockquote>
+
+<blockquote>
+<h4>Symptoms</h4>
+<p>
For a JDBC ResultSet with type TYPE_FORWARD_ONLY, the methods
rowUpdated, rowDeleted and rowInserted could previously be called
while not on a row, i.e. before positioning in the result set, while
@@ -633,11 +670,6 @@
before new positioning and when after last row. This is now
disallowed.
</p>
-</ul>
-</blockquote>
-
-<blockquote>
-<h4>Symptoms</h4>
<p>
Calls to any of these methods while not on a row will now throw
SQLException with SQLState 24000.
@@ -683,13 +715,9 @@
</h3>
<h4>Problem</h4>
<p>
-The optimizer will now abandon sub-optimal join orders as soon as it realizes that they cost more than the best join order so far.
+Performance may change for queries with nested subqueries and/or large
+ FROM clauses.
</p>
-
-<p>
-This fix also ensures that, in the case of short-circuited join orders, Derby will still generate (and execute) an overall plan that matches the "best path" decisions made by the optimizer--which was not always the case prior to these changes.
-</p>
-</ul>
</blockquote>
<blockquote>
@@ -716,11 +744,10 @@
<blockquote>
<h4>Workaround</h4>
<p>
-There is no way to disable/workaround this new behavior since the symptom as described above is a good one for Derby.
-</p>
-
-<p>
-That said, any user who notices a negative performance change after
+In general, the performance of these queries should stay the same or
+ improve. However, it is possible that performance may degrade
+ for some queries.
+Any user who notices a negative performance change after
moving to Derby 10.2, and who believes that the difference in
performance is related to this optimizer change, is encouraged to
visit the
@@ -737,7 +764,7 @@
</h3>
<h4>Problem</h4>
<p>
-Default BLOB/CLOB length should be the maximum length supported by Derby (2G-1)
+Maximum BLOB/CLOB length has increased to 2G-1.
</p>
</ul>
</blockquote>
@@ -745,7 +772,7 @@
<blockquote>
<h4>Symptoms</h4>
<p>
-An application that used BLOB will current reject values greater than 1M, changing the default means the application will now silently accept those values.
+Previously, Derby rejected BLOB lengths greater than 1M.
</p>
</blockquote>
@@ -777,132 +804,23 @@
<hr/>
<blockquote>
<h3>
-<a name="1621"></a>
-<a href="http://issues.apache.org/jira/browse/DERBY-1621">DERBY-1621</a>
+<a name="1652"></a>
+<a href="http://issues.apache.org/jira/browse/DERBY-1652">DERBY-1652</a>
</h3>
-<h4>Problem</h4>
-<p>
-Trigger action statement is not recompile when there is a change that would affect it.
-</p>
-</ul>
</blockquote>
-
-<blockquote>
-<h4>Symptoms</h4>
-<p>
-(1) Trigger action such as an INSERT statement does not get recompiled when the underlying
-table is affected by a CREATE or DROP INDEX statement. e.g.:
-</p>
-
-<blockquote><pre>
- create table t (i int);
- create table t2 (i int);
- create trigger tt after insert on t for each statement mode db2sql insert into t2 values 1;
- insert into t values 1;
- select * from t2;
- create unique index tu on t2(i);
- insert into t values 1;
- select * from t2;
- insert into t values 1;
- 1 row inserted/updated/deleted
-</pre></blockquote>
-
-<p>
-The above example creates an unique index on table t2. when the trigger is fired, it did not
-raise an unique constraint error.
-</p>
-
-<p>
-(2) When the trigger action statement underlying view gets dropped, the trigger statement did not get
-recompiled. e.g.:
-</p>
-
-<blockquote><pre>
- create table t11 (c111 int not null primary key, c112 int);
- insert into t11 values(1,1);
- insert into t11 values(2,2);
- create view v21 as select * from user1.t11;
- create table t31 (c311 int);
- create table t32 (c321 int);
- create trigger tr31t31 after insert on t31 for each statement mode db2sql insert into t32 values (select c111 from user1.v21 where c112=1);
- insert into t31 values(1);
- select * from t31;
- select * from t32;
- drop view v21;
- insert into t31 values(1);
-</pre></blockquote>
-
-<p>
-In the above example, a view which the trigger action references is dropped; however, the last SQL
-INSERT statement did not throw an error.
-</p>
-
-<p>
-(3) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger.
-The trigger action is not being recompiled and raises SQLSTATE XSAI2 even though the table being
-dropped was recreated again. e.g.:
-</p>
-
-<blockquote><pre>
- create table t1 (id int, name varchar(20));
- create table t2 (id int);
- create trigger test_trigger after insert on t2 for each row mode db2sql insert into t1 values(100, 'hundred');
- insert into t2 values(1);
- insert into t2 values(1);
- select * from t1;
- drop table t1;
- insert into t2 values(1);
- create table t1 (id int, name varchar(20));
- insert into t2 values(1);
-</pre></blockquote>
-
-<p>
-In the above example, a table which the trigger action references is dropped. The last INSERT
-statement should execute successfully but it raises SQLSTATE XSAI2: The conglomerate (896)
-requested does not exist.
-</p>
-</blockquote>
-
-<blockquote>
-<h4>Cause</h4>
-<p>
-Derby did not perform invalidation of the trigger action when object(s) that the trigger
-references are modified or dropped; hence, resulting in the stated problem above. The
-affected versions are Derby 10.0 and 10.1.
-</p>
-</blockquote>
-
<blockquote>
-<h4>Solution</h4>
-<p>
-A fix to resolve the above Derby symptoms is available in 10.2.
-</p>
-</blockquote>
-
-<blockquote>
-<h4>Workaround</h4>
+<h4>Problem</h4>
<p>
-None.
+Recursive trigger firing disallowed.
</p>
</blockquote>
-
-<hr/>
<blockquote>
-<h3>
-<a name="1652"></a>
-<a href="http://issues.apache.org/jira/browse/DERBY-1652">DERBY-1652</a>
-</h3>
-<h4>Problem</h4>
+<h4>Symptoms</h4>
<p>
In some cases, an after update trigger does not get fired upon itself when its trigger action contains
an update statement on the trigger's subject table.
</p>
-</ul>
-</blockquote>
-
-<blockquote>
-<h4>Symptoms</h4>
<p>
(1) When defining a trigger for the first time for a table, e.g.:
</p>
@@ -950,7 +868,7 @@
<blockquote>
<h4>Cause</h4>
<p>
-Derby's did not generate the correct execution plan for self-trigger invocation when such a trigger is declared
+Derby did not generate the correct execution plan for self-trigger invocation when such a trigger is declared
for the first time on the subject table; hence, resulting in the stated problem above. The affected version is
Derby 10.0 and 10.1.
</p>
@@ -959,8 +877,7 @@
<blockquote>
<h4>Solution</h4>
<p>
-A fix to resolve the above Derby symptom is available in 10.1 and 10.2.
-thrown now.
+This behavior has been corrected in 10.2.
</p>
</blockquote>
@@ -1043,11 +960,11 @@
<li><b>Ant</b> - Apache Ant version 1.6.5 compiled on June 2 2005.</li>
<li><b>JDK 1.3</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_19-b03).</li>
<li><b>JDK 1.4</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03).</li>
-<li><b>JDK 1.6</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0).</li>
+<li><b>JDK 1.6</b> - Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-b105).</li>
<li><b>OSGi</b> - The osgi.jar was used to build org.apache.derby.osgi.EmbeddedActivator.</li>
<li><b>Compiler</b> - The 1.4.2_12-b03 javac was used to compile all
classes except for the JDBC4 drivers. The JDBC4 driver classes were compiled
- using the 1.6.0 javac.</li>
+ using the 1.6.0-b105 javac.</li>
<li><b>JSR 169</b> - J2ME support was built using java.sun.com/j2me (j2me_cdc_fp-1_0_2).</li>
</ul>