Return-Path: Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 9461 invoked by uid 500); 7 Oct 2004 18:31:33 -0000 Delivered-To: apmail-incubator-derby-cvs@incubator.apache.org Received: (qmail 9458 invoked by uid 99); 7 Oct 2004 18:31:32 -0000 X-ASF-Spam-Status: No, hits=-9.9 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME,UPPERCASE_25_50 X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.28) with SMTP; Thu, 07 Oct 2004 11:31:31 -0700 Received: (qmail 65618 invoked by uid 65534); 7 Oct 2004 18:31:29 -0000 Date: 7 Oct 2004 18:31:29 -0000 Message-ID: <20041007183129.65615.qmail@minotaur.apache.org> From: djd@apache.org To: derby-cvs@incubator.apache.org Subject: svn commit: rev 54005 - incubator/derby/site/trunk/src/documentation/content/xdocs X-Virus-Checked: Checked Author: djd Date: Thu Oct 7 11:31:29 2004 New Revision: 54005 Modified: incubator/derby/site/trunk/src/documentation/content/xdocs/DerbyToDo.ihtml Log: Update the to-do document based upon discussions in the mailing lists. Modified: incubator/derby/site/trunk/src/documentation/content/xdocs/DerbyToDo.ihtml ============================================================================== --- incubator/derby/site/trunk/src/documentation/content/xdocs/DerbyToDo.ihtml (original) +++ incubator/derby/site/trunk/src/documentation/content/xdocs/DerbyToDo.ihtml Thu Oct 7 11:31:29 2004 @@ -1,1062 +1,1216 @@ - - - - - Apache Derby: To-Do List - - - - - - - - -

Overview

Last Update 2004/08/12

This is a list of work items for Derby that are either actively -been worked on, potential new items or items that were rejected by -the community. Completed items will remain on the list for some time, -e.g. Until they are documented and part of a stable line. This is -only for items related to the Java code. Documentation, integration -white-papers and web-site items are not covered here.

Bugs are tracked separately in the Jira bug tracking system at -<LINK TO JIRA>.

As possible new items get discussed or requested on the user or -developer mailing lists, or from any other channel, they should be -added here.

The explanation of the columns are:

First column – feature description.
-
Approved – Approval state
-
blank - no vote has been taken
-
Yes - item has been approved. Some linkage will be - provided to the vote, e.g. Date of vote.
-
No – item was not approved by the community. - Some linkage will be provided to the vote.
-
Contact – Contributors either actively working - on the item, or have some knowledge of the item.
If blank then - get involved by starting a discussion of the item on the developer - mailing list. See the 'how it works' for details.
If not blank - and you are interested then contact the current contributors to see - how you can help out.
-
Progress – Some description of where the item - stands.
-
Comments – More information on the feature, - maybe a link to a fuller description of the item, indication of - interest in the item etc.
-

Features

SQL

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- SQL Feature -	- Approved -	- Contact -	- Progress -	- Comments -
- GRANT/REVOKE -	- - -	- - -	- none -	- Standard SQL92, some demand from community. -
- SQL/XML -	- - -	- Armageddon R Brown, Satheesh Bandaram, Cliff Leung -	- Prototype code -	- XML data type and SQL/XML functions using Xerces as the - parser. Need to break this into separate items, one per - conformance item in SQL/XML. -
- XQuery support -	- - -	- Armageddon R Brown, Satheesh Bandaram, Cliff Leung -	- Prototype code -	- Some prototype code for Xpath expressions. -
- SPECIFIC name for PROCEDUREs and FUNCTIONs -	- - -	- - -	- Catalogs and parser are set up to handle a SPECIFIC name. -	- SPECIFIC name is a step towards overloading of PROCEDUREs and - FUNCTIONs. -
- Overloading of PROCEDUREs and FUNCTIONs -	- - -	- - -	- none -	- Allows multiple PROCEDUREs and FUNCTIONs with the same name - but different parameter types. -
- SQL Procedure language -	- - -	- - -	- none -	- Would need to be standard based but then would that limit its - use as applications that use it might not be able to migrate up - to other databases. Need to investigate overlap of standard - options with vendor specific procedure language. -
- TRUNCATE TABLE -	- - -	- Suresh Thalamati -	- Code basically complete in engine, needs to be exposed -	- Details of rollback behaviour to be clarified. -
- National character types (NCHAR etc.) -	- - -	- - -	- Code basically complete in engine, need to be exposed and - verified with SQL standard. -	- Code could also use cleanup and ensure casts between types is - handled correctly. -
- Multi-version concurrency locking (like Oracle, MySQL etc.) -	- - -	- - -	- None -	- - -

JDBC

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- JDBC Feature -	- Approved -	- Contact -	- Progress -	- Comments -
- Updateable ResultSets -	- - -	- Mamta Satoor -	- concept -	- JDBC 3.0 -
- Support update methods in java.sql.{Blob,Clob} -	- - -	- - -	- none -	- - -
- JDBC 4.0 support -	- - -	- - -	- Place-holder -	- JDBC 4.0 specification is in progress as JSR 221. Most likely - this would split into a number of items, one per feature of JDBC - 4.0. -
- Query timeout -	- - -	- - -	- concept -	- Java.sql.Statement.setQueryTimeout -
- JSR 169 support JDBC Optional Package for CDC/Foundation - Profile - -	- - -	- Dan Debrunner, Myrna Van lunteren -	- Partial framework -	- Requires J2ME/CDC/Foundation support. Convert old framework - for JDBC 1.2 support to JSR169. -
- XA support with Network Server -	- - -	- Katherine Marsden -	- Prototype code -	- Support for JCC's java.sql.XADataSource implementation for use - in application servers. -
- Support java.sql.Statement.cancel() - -	- - -	- - -	- None -	- related to query timeout -

Platform -Support

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- Platform Support -	- Approved -	- Contact -	- Progress -	- Comments -
- J2ME/CDC/Foundation support -	- - -	- Dan Debrunner, Myrna Van lunteren -	- Some initial work already in -	- Need to remove use of classes that are not in the profile, - such as java.math.BigDecimal, java.util.Stack, etc. Set up - compile to use those libraries as the base compile class path. -
- OSGi ee.minimum support -	- - -	- Dan Debrunner, Myrna Van lunteren -	- Some initial work already in -	- Is a sub-set of J2ME/CDC/Foundation -
- JDK 1.5 -	- - -	- - -	- Place holder -	- Look into seeing if there are specific features of JDK 1.5 - that would benefit Derby.Most likely would split into multiple - items. -
- J2EE 1.5 -	- - -	- - -	- Place holder -	- Specific JBDC requirements of J2EE 1.5.Most likely would split - into multiple items. -

Other

Miscellaneous features, such as extensibility (pluggable code), or -security features.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- Platform Support -	- Approved -	- Contact -	- Progress -	- Comments -
- Dynamic swap of derby.log -	- - -	- - -	- none -	- Better mechanisms for handling the error log with a long - running system. E.g. Switch log files every 100k bytes. -
- Backup directly to jar file -	- - -	- - -	- none -	- Make the backup code directly create a jar file. Allows easy - creation of jar files for 'database-in-a jar 'feature -
- Generate run time statistics output in XML format -	- - -	- - -	- none -	- Might reduce footprint by not requiring specific classes for - each ResultSet type -
- Text search/indexing -	- - -	- - -	- none -	- Pluggable mechanism to support text indexing engines, how to - make SQL queries standard? -
- Migration tool -	- - -	- - -	- None -	- Support migration from an existing JDBC database to Derby. - Support any JDBC database with standard datatypes and older - Cloudscape releases. -
- In-memory database -	- - -	- Jack Klebanoff -	- Prototype code -	- Implementation of the org.apache.derby.io package that - provides an in-memory database -
- Single file per database -	- - -	- - -	- None -	- Rather than a single file per table. -
- Property validation (derby.*) -	- - -	- - -	- Framework and validation for some properties -	- Validation for all properties -

Performance/Zero Admin/Footprint

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- Platform Support -	- Approved -	- Contact -	- Progress -	- Comments -
- Smarter query recompilation -	- - -	- - -	- Some ideas -	- The current scheme of check every N iterations is simplistic - and can be expensive. Also information about which piece of the - query was badly estimated is there but not used. -
- Autonomic checkpointing timing and log file size -	- - -	- Sunitha Kambhampati -	- Some ideas -	- Current checkpoint interval and log file saize can be - configured, but engine should self-configure. -
- Use of idle time for background checkpoint -	- - -	- - -	- - -	- - -
- Optimizer overrides -	- - -	- Satheesh Bandaram -	- Overrides exist in the code but are not exposed -	- Provide optimizer overrides (e.g force join order) using a - mechanism that does not require the application's SQL to change - (and thus become non-portable). E.g. A separate configuration - that indicates the join order for a SQL text string. -
- Single background thread -	- - -	- Dan Debrunner -	- ideas -	- Currently one background thread is created per database, which - becomes an issue when supporting thousands of databases per JVM. -
- Improved statement plan cache -	- - -	- Dan Debrunner -	- Some framework code exists -	- Make single-use (DDL) statements indicate they don't need to - be cached, support single plan regardless of compilation schema - if they do not depend on the current schema -
- Background space re-claiming -	- - -	- Mike Matrigali -	- Some design -	- Allow space to be returned to the operating system by - truncating files. Have to move rows around dynamically etc. -
- Support super-simple configuration of single configuration - parameter – how much total memory to use -	- - -	- - -	- Some memory based sizing support for the cache -	- All caches would re-size themselves based upon the value and - their size and number of connections etc. -
- Backward scan in index -	- - -	- - -	- ?? -	- - -
- Implement limt on on-disk database size -	- - -	- - -	- None -	- Limit database growth. -

Code Cleanup

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- Platform Support -	- Approved -	- Contact -	- Progress -	- Comments -
- - -	- - -	- - -	- - -	- - -
- - -	- - -	- - -	- - -	- - -
- - -	- - -	- - -	- - -	- - -

- - + + + + + Apache Derby: To-Do List + + + + + + + + +

Overview

Last Update 2004/10/07

This is a list of work items for Derby that are either actively +been worked on, potential new items or items that were rejected by +the community. Completed items will remain on the list for some time, +e.g. Until they are documented and part of a release. This is only +for items related to the Java code. Documentation, integration +white-papers and web-site items are not covered here.

Bugs are tracked separately in the Jira bug tracking system at +http://issues.apache.org/jira/browse/DERBY. +Feature requests may also exist in Jira.

As possible new items get discussed or requested on the user or +developer mailing lists, or from any other channel, they should be +added here.

The explanation of the columns are:

First column – feature description.
+
Approved – Approval state
+
blank - no vote has been taken
+
Yes - item has been approved. Some linkage will be + provided to the vote, e.g. Date of vote.
+
No – item was not approved by the community. + Some linkage will be provided to the vote.
+
Contact – Contributors either actively working + on the item, or have some knowledge of the item.
If blank then + get involved by starting a discussion of the item on the developer + mailing list. See the 'how it works' for details.
If not blank + and you are interested then contact the current contributors to see + how you can help out.
+
Progress – Some description of where the item + stands.
+
Comments – More information on the feature, + maybe a link to a fuller description of the item, indication of + interest in the item etc.
+

Features

SQL

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ SQL Feature +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ ALTER TABLE DROP COLUMN +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ COMMENT ON +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ User Defined Types +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ Increased SQL identifier lengths +	+ + +	+ derby-dev + thread + and mentions in a couple of other threads +	+ + +	+ + +
+ Gist indexing (spatial) +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ Localized character sorting +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ GRANT/REVOKE +	+ + +	+ + +	+ none +	+ Standard SQL92, some demand from community. +
+ SQL/XML +	+ + +	+ Armageddon R Brown, Satheesh Bandaram, Cliff Leung +	+ Prototype code +	+ XML data type and SQL/XML functions using Xerces as the + parser. Need to break this into separate items, one per + conformance item in SQL/XML. +
+ XQuery support +	+ + +	+ Armageddon R Brown, Satheesh Bandaram, Cliff Leung +	+ Prototype code +	+ Some prototype code for Xpath expressions. +
+ SPECIFIC name for PROCEDUREs and FUNCTIONs +	+ + +	+ + +	+ Catalogs and parser are set up to handle a SPECIFIC name. +	+ SPECIFIC name is a step towards overloading of PROCEDUREs and + FUNCTIONs. +
+ Overloading of PROCEDUREs and FUNCTIONs +	+ + +	+ derby-dev + thread +	+ none +	+ Allows multiple PROCEDUREs and FUNCTIONs with the same name + but different parameter types. +
+ SQL Procedure language +	+ + +	+ + +	+ none +	+ Would need to be standard based but then would that limit its + use as applications that use it might not be able to migrate up + to other databases. Need to investigate overlap of standard + options with vendor specific procedure language. +
+ TRUNCATE TABLE +	+ + +	+ Suresh Thalamati +	+ Code basically complete in engine, needs to be exposed +	+ Details of rollback behaviour to be clarified. +
+ National character types (NCHAR etc.) +	+ + +	+ + +	+ Code basically complete in engine, need to be exposed and + verified with SQL standard. +	+ Code could also use cleanup and ensure casts between types is + handled correctly. +
+ Multi-version concurrency locking (like Oracle, MySQL etc.) +	+ + +	+ + +	+ None +	+ + +

JDBC

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ JDBC Feature +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ Updateable ResultSets +	+ + +	+ Mamta Satoor + derby-dev + thread +	+ Actively being worked on +	+ JDBC 3.0 +
+ Support update methods in java.sql.{Blob,Clob} +	+ + +	+ + +	+ none +	+ + +
+ JDBC 4.0 support +	+ + +	+ + +	+ Place-holder +	+ JDBC 4.0 specification is in progress as JSR 221. Most likely + this would split into a number of items, one per feature of JDBC + 4.0. +
+ Query timeout +	+ + +	+ DERBY-31 +	+ concept +	+ Java.sql.Statement.setQueryTimeout +
+ JSR 169 support JDBC Optional Package for CDC/Foundation + Profile + +	+ + +	+ Dan Debrunner, Myrna Van lunteren + derby-dev + thread +	+ Actively being worked on +	+ Requires J2ME/CDC/Foundation support. Convert old framework + for JDBC 1.2 support to JSR169. +
+ XA support with Network Server +	+ + +	+ Katherine Marsden DERBY-10 +	+ Actively being worked on +	+ Support for JCC's java.sql.XADataSource implementation for use + in application servers. +
+ Support java.sql.Statement.cancel() + +	+ + +	+ + +	+ None +	+ related to query timeout +

Platform +Support

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Platform Support +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ J2ME/CDC/Foundation support +	+ + +	+ Dan Debrunner, Myrna Van lunteren + (See JSR169) +	+ Actively being worked on +	+ Need to remove use of classes that are not in the profile, + such as java.math.BigDecimal, java.util.Stack, etc. Set up + compile to use those libraries as the base compile class path. +
+ OSGi ee.minimum support +	+ + +	+ Dan Debrunner, Myrna Van lunteren + (See JSR169) +	+ Some initial work already in +	+ Is a sub-set of J2ME/CDC/Foundation +
+ JDK 1.5 +	+ + +	+ + +	+ Place holder +	+ Look into seeing if there are specific features of JDK 1.5 + that would benefit Derby.Most likely would split into multiple + items. +
+ J2EE 1.5 +	+ + +	+ + +	+ Place holder +	+ Specific JBDC requirements of J2EE 1.5.Most likely would split + into multiple items. +

Other

Miscellaneous features, such as extensibility (pluggable code), or +security features.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Platform Support +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ Dynamic swap of derby.log +	+ + +	+ + +	+ none +	+ Better mechanisms for handling the error log with a long + running system. E.g. Switch log files every 100k bytes. +
+ Backup directly to jar file +	+ + +	+ + +	+ none +	+ Make the backup code directly create a jar file. Allows easy + creation of jar files for 'database-in-a jar 'feature +
+ Generate run time statistics output in XML format +	+ + +	+ + +	+ none +	+ Might reduce footprint by not requiring specific classes for + each ResultSet type +
+ Text search/indexing +	+ + +	+ + +	+ none +	+ Pluggable mechanism to support text indexing engines, how to + make SQL queries standard? +
+ Migration tool +	+ + +	+ + +	+ None +	+ Support migration from an existing JDBC database to Derby. + Support any JDBC database with standard datatypes and older + Cloudscape releases. +
+ In-memory database +	+ + +	+ Jack Klebanoff +	+ Prototype code +	+ Implementation of the org.apache.derby.io package that + provides an in-memory database +
+ Single file per database +	+ + +	+ + +	+ None +	+ Rather than a single file per table. +
+ Property validation (derby.*) +	+ + +	+ + +	+ Framework and validation for some properties +	+ Validation for all properties +

Performance/Zero Admin/Footprint

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Platform Support +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ Query re-writes for queries with constants +	+ + +	+ derby-dev + thread +	+ + +	+ + +
+ Smarter query recompilation +	+ + +	+ + +	+ Some ideas +	+ The current scheme of check every N iterations is simplistic + and can be expensive. Also information about which piece of the + query was badly estimated is there but not used. +
+ Autonomic checkpointing timing and log file size +	+ + +	+ Sunitha Kambhampati +	+ Some ideas +	+ Current checkpoint interval and log file saize can be + configured, but engine should self-configure. +
+ Use of idle time for background checkpoint +	+ + +	+ + +	+ + +	+ + +
+ Optimizer overrides +	+ + +	+ Satheesh Bandaram +	+ Overrides exist in the code but are not exposed +	+ Provide optimizer overrides (e.g force join order) using a + mechanism that does not require the application's SQL to change + (and thus become non-portable). E.g. A separate configuration + that indicates the join order for a SQL text string. +
+ Single background thread +	+ + +	+ Dan Debrunner +	+ ideas +	+ Currently one background thread is created per database, which + becomes an issue when supporting thousands of databases per JVM. +
+ Improved statement plan cache +	+ + +	+ Dan Debrunner +	+ Some framework code exists +	+ Make single-use (DDL) statements indicate they don't need to + be cached, support single plan regardless of compilation schema + if they do not depend on the current schema +
+ Background space re-claiming +	+ + +	+ Mike Matrigali +	+ Some design +	+ Allow space to be returned to the operating system by + truncating files. Have to move rows around dynamically etc. +
+ Support super-simple configuration of single configuration + parameter – how much total memory to use +	+ + +	+ + +	+ Some memory based sizing support for the cache +	+ All caches would re-size themselves based upon the value and + their size and number of connections etc. +
+ Backward scan in index +	+ + +	+ + +	+ ?? +	+ + +
+ Implement limt on on-disk database size +	+ + +	+ + +	+ None +	+ Limit database growth. +

Code Cleanup

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Platform Support +	+ Approved +	+ Contact +	+ Progress +	+ Comments +
+ + +	+ + +	+ + +	+ + +	+ + +
+ + +	+ + +	+ + +	+ + +	+ + +
+ + +	+ + +	+ + +	+ + +	+ + +

+ + \ No newline at end of file