Currently, this is a dump from the old, outdated, and obsolete DerbyToDo page that was on the website. This page serves to maintain items that were on that page that do not have JIRA issues filed until such time as JIRA issues can be filed.

Please update and correct any information you find on this page as necessary. If the item has a JIRA filed and no further action is necessary at this time, feel free to remove that line from the table.

SQL

Feature

discussion

JIRA

comments

ALTER TABLE DROP COLUMN

many

DERBY-1489

COMMENT ON

derby-dev thread

User Defined Types

derby-dev thread

DERBY-672 (?)

Gist indexing (spatial)

derby-dev thread

Localized character sorting

derby-dev thread and more

related to DERBY-533

related to NCHAR etc. support

SQL/XML / XQuery

many

mostly in 10.2?

SPECIFIC name for PROCEDUREs and FUNCTIONs

SPECIFIC name is a step towards overloading of PROCEDUREs and FUNCTIONs.

Overloading of PROCEDUREs and FUNCTIONs

derby-dev thread

Allows multiple PROCEDUREs and FUNCTIONs with the same name but different parameter types.

SQL/PSM

wiki more elsewhere

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

Code basically complete in engine, needs to be exposed. Details of rollback behaviour to be clarified.

National character types (NCHAR etc.)

DERBY-533

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

JDBC

Feature

discussion

JIRA

comments

Updateable ResultSets

complete in 10.2?

Support update methods in java.sql.{Blob,Clob}

?

JDBC 4.0 support

mostly complete in 10.2 pending finalization of JDBC 4 spec

Query timeout

DERBY-31

Complete in 10.2

Support java.sql.Statement.cancel()

?

Platform Support

Feature

discussion

JIRA

comments

OSGi ee.minimum support

JDK 5.0

some discussion of NIO

DERBY-810

Look into seeing if there are specific features of JDK 5.0 that would benefit Derby.Most likely would split into multiple items.

J2EE 5.0

Place holder - Specific JBDC requirements of J2EE 5.0. Most likely would split into multiple items.

Other - Miscellaneous features

Feature

discussion

JIRA

comments

Dynamic swap of derby.log

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

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

Might reduce footprint by not requiring specific classes for each ResultSet type

Text search/indexing

many

DERBY-472

Pluggable mechanism to support text indexing engines, how to make SQL queries standard?

Migration tool

Google SoC project

DERBY-1651

In-memory database

many

DERBY-646

Single file per database

Rather than a single file per table.

Property validation

Framework and validation for some properties

JMX Support

Google SoC project

DERBY-1387

Cache Manager Support

Google SoC project

DERBY-1437

Performance/Zero Admin/Footprint

Feature

discussion

JIRA

comments

Query re-writes for queries with constants

derby-dev thread

Smarter query recompilation

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

some - need reference

Current checkpoint interval and log file size can be configured, but engine should self-configure.

some - need reference

Use of idle time for background checkpoint

some - need reference (see threads by Raymond Raymond)

Single background thread

Currently one background thread is created per database, which becomes an issue when supporting thousands of databases per JVM.

Improved statement plan cache

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

some - need reference

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

All caches would re-size themselves based upon the value and their size and number of connections etc.

Backward scan in index

some - need reference

Implement limt on on-disk database size

some - need reference

DerbyToDos (last edited 2009-09-20 22:11:43 by localhost)