db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rhille...@apache.org
Subject svn commit: r488358 - /db/derby/code/branches/10.2/RELEASE-NOTES.html
Date Mon, 18 Dec 2006 17:34:40 GMT
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>
 



Mime
View raw message