db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "HighValueFixCandidates" by KatheyMarsden
Date Tue, 06 Jun 2006 18:27:12 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by KatheyMarsden:
http://wiki.apache.org/db-derby/HighValueFixCandidates

------------------------------------------------------------------------------
   * Risk to existing users if the fix is implemented.
   * Severity of the issue.
   * Availability of a workaround.
-   
+  * The amount of user/developer time is wasted by the issue.
  
  Listings are by branch as some fixes are not appropriate for the maintenance branches. 
Please add issues to the lists or remove/move them if they do not seem appropriate for the
branch.
  
@@ -22, +22 @@

  ||[http://issues.apache.org/jira/browse/DERBY-1018 DERBY-1018]||  Client xa Statement.getConnection
and DatabaseMetadata.getConnection returns underlying NetXAConnection instead of Logical connection||
	||
  ||[http://issues.apache.org/jira/browse/DERBY-1020 DERBY-1020]|| 	Network Server treats
errors on cleanup of connections as an unexpected error after intentional shutdown of the
database/server|| 	||
  ||[http://issues.apache.org/jira/browse/DERBY-1107 DERBY-1107]|| 	 For existing databases
JDBC metadata queries do not get updated properly between maintenance versions.|| 	||
- ||[http://issues.apache.org/jira/browse/DERBY-1183 DERBY-1183]|| 	Client java.sql.ResultSet.getCursorName()
does not return the correct cursor name for Statements after the first execution|| 	||
+ ||[http://issues.apache.org/jira/browse/DERBY-1183 DERBY-1183]|| 	Client java.sql.ResultSet.getCursorName()
does not return the correct cursor name for Statements after the first execution|| The user
cannot even workaround this issue by calling setCursorName() again. May be low hanging fruit||
  ||[http://issues.apache.org/jira/browse/DERBY-1191 DERBY-1191]|| 	Some SQLExceptions, for
example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0||
	||
  ||[http://issues.apache.org/jira/browse/DERBY-1204 DERBY-1204]|| 	CREATE TRIGGER with an
INSERT action statement with multiple rows and a referenced column throws a StringIndexOutOfBoundsException||
	||
  ||[http://issues.apache.org/jira/browse/DERBY-1219 DERBY-1219]|| 	jdbcapi/checkDataSource.java
and jdbcapi/checkDataSource30.java hang intermittently with client|| 	||
@@ -59, +59 @@

  These are major fixes that are important to users but may not appropriate for the maintenance
branch. Of course once fixed, they can be evaluated and maybe port to 10.1 will be fine.
  
  || JIRA_ISSUE   ||  SUMMARY    	|| COMMENTS ||
+ ||[http://issues.apache.org/jira/browse/DERBY-47  DERBY-47]|| IN Optimization issues ||This
issue and its clone  [http://issues.apache.org/jira/browse/DERBY-713 DERBY-713] represent
10 votes in Jira and it make it by far the most popular issue.  The performance impact of
this issue on many users is significant enough for them to file it a bug although we have
it filed as an improvement||
  ||[http://issues.apache.org/jira/browse/DERBY-550  DERBY-550]||BLOB : java.lang.OutOfMemoryError
with network JDBC driver with setBinaryStream || Client always materializes the LOB, even
when using setBinaryStream.  This is the client side equivalent of [http://issues.apache.org/jira/browse/DERBY-326
DERBY-326] ||
  || [http://issues.apache.org/jira/browse/DERBY-700  DERBY-700]   || Derby does not prevent
dual boot of database from different classloaders on Linux || Dual boot and corruption of
the db should never be allowed and more and more users are using custom class loaders. This
is being reported more and more ||
  || [http://issues.apache.org/jira/browse/DERBY-634 DERBY-634 ]   ||  Subquery materialization
can cause stack overflow || Reported by users and has potential to become a frequently hit
scalability issue for DERBY queries ||

Mime
View raw message