[Db-derby Wiki] Update of "HighValueFixCandidates" by KatheyMarsden

[Apache Wiki <wi...@apache.org>]

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 ||