List of things to be done for the next version of DdlUtils:

* Fix Javadoc errors
* Enhance doc:
    - How to use DdlUtils in code
* Separate generation of alter statements for an existing databases from the reading
  of the model from the existing database to allow for alter statement generation with two
  database models without having to connect to the database and thus allow for testing the
  alter statement generation without an actual live database
* Add unit tests for:
    - SQL generation (including alteration)
    - Roundtrip (database specific)
* Replace usage of java.util.regex with some alternative that is Java 1.3 (1.2 ?) compatible
* Add support for chosing the character set (ASCII, UNICODE) if the database supports it
  (perhaps a more generic configuration mechanism for overriding defaults)
* Add the ability to configure the datatype mapping (ant task, API)
* Replace System.out/System.err writes with logging statements
* Extract interfaces from the model classes and inroduce a factory for creating the concrete model objects
* Add functionality and ant tasks to dump data from the database
* Add integration with DbUnit to allow DbUnit to use the schema and data files
* Add notion of jdbc types not directly supported by the database which are mapped to some large binary type,
  and add warnings when they are used (-> logging)
* It might be useful to add support for the ARRAY jdbc data type in the way that PostgreSQL does, by
  simply adding brackets to the base type instead of using the ARRAY literal as this does not define the base
  type at all
* It would be helpful if the platform impl check the length of user-supplied identifiers (table names,
  column names, fk names, index names) before any SQL is send to the database
* Add check for databases that only support one auto-increment field (eg. MySQL, HsqlDb, McKoi)
* Add ability to specify the sorting direction of an index-column (ascending/descending) - this is at least supported in Derby
* Rather than dropping the indices/foreign keys that are at the current table, it would be better to simply drop any
  of the constraints/triggers connected to a table (if that is possible)