JRF Version 2.0 Release Notes

Overview

This version includes modifications that overlap four broad categories: functionality improvements, speed enhancements, architectural changes, and code generation. The architectural changes, although extensive, do not violate the original design paradigm of JRF, which centers around PersistentObject instances and the AbstractDomain sub-classes that manipulate these instances. However, the architectural changes included in this release will require application code modifications. The most significant change to JRF architecturally is the elimination of the JDBCHelper class from the framework. The functionality and much of the code of JDBCHelper still exists in smaller, task-specific classes. If an application does not make extensive use of direct JDBCHelper calls in AbstractDomain contexts, code modifications will be fairly minimal. See Modifying Existing Code with JDBCHelper Arguments for complete details on how to modify existing JRF applications.

Code generation is no longer an ancillary piece of JRF, it is now a central part of the framework. While it is certainly possible to hand-write most of your PersistentObjects and AbstractDomains, you no longer have to do this. Two code generators are provided, one for generating base direct table-to-object mappings and one for generating composite objects that may include detail tables, join columns or both. These generators are extensible in several ways. First, since the code generators read XML files for the information, you can add more values in the DTD (Document Type Definition) files to expand the functionality. You can also sub-class the code generation entity handling classes for table, column and so forth. Finally, you can sub-class the generators themselves if you want even more control.

A short term "todo" is to write a program that will read the database metadata and generate a skeletal XML file that may be used by the base generator.

Functionality Improvements

Application row handlers and application determination of data storage mechanism for queries. Under previous versions of JRF, the framework returned data from an SQL SELECT statement in only two formats: a single PersistentObject instance for primary key fetches or a java.util.List of PersistentObjects for multiple row fetches. Under this version, application developers may implement an interface called ApplicationRowHandler, which will allow them to store data in any format they choose and even abort a large multi-row fetch if desired. This interface is basically one level of abstraction up from the existing protected RowHandler interface in AbstractDomain. Whereas RowHandler requires a sub-class of AbstractDomain to process a java.sql.ResultSet, ApplicationRowHandler can be implemented outside the domain and processes a PersistentObject instance already constructed by the framework. Some convenient default implementations of ApplicationRowHandler are provided in the framework.

Column Options. Constructors for the implementations of ColumnSpec have been streamlined with the introduction of class net.sf.jrf.column.ColumnOption. Introducing this class has eliminated the need for multiple constructors in the specification class implementations. For example, this following:

			this.addSubtypeColumnSpec(
			        new StringColumnSpec(
			            "DepartmentCode",      // column name
			            "getDepartmentCode",   // getter
			            "setDepartmentCode",   // setter
			            ColumnSpec.DEFAULT_TO_EMPTY_STRING,
			            ColumnSpec.REQUIRED));

should be replaced with:

			this.addSubtypeColumnSpec(
			        new StringColumnSpec(
			            "DepartmentCode",      // column name
					   new RequiredColumnOption(),
			            "getDepartmentCode",   // getter
			            "setDepartmentCode",   // setter
			            ColumnSpec.DEFAULT_TO_EMPTY_STRING);

ColumnOption is simply a wrapper for the existing options:

			public abstract class ColumnOption
			{

			  protected boolean i_required = false;
			  protected boolean i_primaryKey = false;
			  protected boolean i_sequencedPrimaryKey = false;
			  protected boolean i_naturalPrimaryKey = false;
			  protected boolean i_unique = false;
			  protected boolean i_subtypeIdentifier = false;
			  protected boolean i_optimisticLock = false;
			  .
			  .

Sub-classes of ColumnOption provide various combinations of the boolean values under one general description. The hierarchy is:

				ColumnOption
					NullableColumnOption
					RequiredColumnOption
						OptimisticLockColumnOption
						PrimaryKeyColumnOption
							NaturalPrimaryKeyColumnOption
							SequencedPrimaryKeyColumnOption 
						UniqueColumnOption 
					SubtypeColumnOption

Primitive Attribute Support. This version allows a user to specify primitives for PersistentObject attributes. For all practical purposes, however, you will need to use the new code generators to implement primitives.
Expanded Caching Support. This verson expands upon the original caching mechanism of AbstractStaticDomain to allow both the caching of all records and the caching of a maximum value of records through an LRU (least-recently-used) mechanism. The implementation of the LRU cache is provided by the Apache Collections project; the common-collections.jar is included in the release. The most important feature introduced is the capability of ensuring that the cache is kept up-to-date with database changes. The limitation, of course, is that the cache will only be valid if all updates are done though the same JVM instance. Caching of composite objects is supported in a limited way. (Future versions will overcome this limitation).
New column specifications. The following new implementations of ColumnSpec exist:
- BinaryStreamColumnSpec
- ByteArrayColumnSpec
- DateColumnSpec (Stored as a date in the database, seen as java.util.Date in the Java space)
- ClobColumnSpec
- BlobColumnSpec
- DayOfWeekColumnSpec (Stored as a locale-specific string in database, seen as Calendar.SUNDAY etc. in Java space).
- SerializableObjectColumnSpec
- BooleanColumnSpecChar1 (Store in database as CHAR(1) "Y/N", "T/F" etc., seen as a boolean in Java space).
Applications that use BinaryStreamColumnSpec, ClobColumnSpec, and BlobColumnSpec must use an ApplicationRowHandler implementation to manipulate data from a query. Once java.sql.ResultSet.next() is called, most JDBC drivers will close all streams on the current row. Thus applications have to be able to access the current row before next() is called by the framework.
Full support for all vendor-specific column expressions required for CREATE TABLE statements. For applications that use AbstractDomain.createTable(), this version now supports optimal column definition expressions statements for CREATE TABLE. There were two general changes made in order to successfully implement this feature:
1. Added DatabasePolicy methods to construct the correct SQL column expressions for binary, text and numeric columns given an appropriate set of parameters. See DatabasePolicy for description and parameter requirements of these methods.
2. Added parameters and reorganized the class hierarchy of applicable ColumnSpec implementations.
The class hierarchy from AbstractColumnSpec is now:
- AbstractColumnSpec
  - SizedColumnSpec (Column types that have a maximum size. A zero value denotes no maximum. Maximum will be restricted to the database vendor's limits)
    - TextColumnSpec (Stores text data)
      - StringColumnSpec
      - StringArrayColumnSpec
      - ClobColumnSpec
    - BinaryColumnSpec (Stores binary data)
      - BinaryStreamColumnSpec
      - ByteArrayColumnSpec
      - SerializableObjectColumnSpec
      - BlobColumnSpec
  - NumericColumnSpec (Stored numeric data with precision and scale)
    - IntegerColumnSpec
    - LongColumnSpec
    - DoubleColumnSpec
    - FloatColumnSpec
    - BooleanColumnSpec
    - NullableBooleanColumnSpec
Expanded support for CREATE TABLE. Methods to create database tables from domains have been expanded to include all required parameters: foreign keys and database storage requirements. The full implementation for all databases is still a job to be done. (see org.vmguys.appgen.jrf.GenerateDatabase).
Simultaneous Multiple Database Support. The singleton DatabasePolicy instance no longer exists in the framework. It is now possible for applications to construct AbstractDomains that connect to to different database vendors seamlessly. See Architectural Changes for more details. Also please examine the documentation if jrf.properties to see how to set up multiple connections.
Robust Connection Management. The JDBC connection management of JRF has been completely overhauled. See Architectural Changes for more details.
Streamlined Transaction Support. In addition to streamlining transaction control, support for handling transactions across multiple databases in now supported. While JRF does not attempt to be JTA compliant, some functionality does exist to handle transactions across databases without using a JTA implementation. See Architectural Changes for more details.
User defined Prepared Statements. An application can define their own prepared statement queries and the AbstractDomain will handle them. (see Speed Enhancements).
Validation Enhancements. Four additional validations are performed in AbstractDomain.validate(). ColumnSpec.validateValue() has been added to check for 1) Strings that exceed the maximum column length in the database (always); 2) Values that exceed a given maximum value (optional); 3) Values that are less than a given minimum value (optional) and 4) values that do not match a set of mandatory values (optional).
Explicit embedded PersistentObject support in AbstractDomain. It has always been possible to construct quite complex PersistentObject instances that may include embedded PersistentObjects. However, application code needed implementations of postFind, postSave and so forth to effectively construct PersistentObject for a fetch operation or deconstruct one for a save operation. In a sense, embedded PersistentObject support was implicit. Support for embedded objects is now explicit in this version. A method now exists in AbstractDomain to support the saving both the master domain object and all embedded objects. See Architectural Changes for more details.
Change of behavior for the return saved object methodology in AbstractDomain. In the previous version of JRF, the default behavior was to refetch the saved object. This functionality was definitely a performance detractor and the default behavior now is to not return the saved object. Modifications to the framework have been made to make every effort to populate the PersistentObject instance passed in for the update with recent values for: 1) sequenced columns; 2) Integer optimistic lock columns. Eventually the framework may be changed to always return something and never null. However, this change has been avoided since it may break the logic of many existing applications.
Split TimeStampColumnSpec into two implementions. The time stamp column for JDBC is a bit confusing and an attempt has been made in the framework to clarify between two separate application uses of a java.sql.Timestamp column: one where the application (client or server) determines the value and one where the database always determines the value through its system timestamp function. The former use has the current class name and the latter uses the name TimeStampColumnSpecDbGen. All timestamp optimistic lock columns should use the new column specification.
Clarification of Sequence Support. Sequence handling and definitions in DatabasePolicy and AbstractDomain have been considerably clarified. See the javadoc for DatabasePolicy for more information. Also, see Embedded Persistent Objects section below.
Aliasing no longer required. Table/Column aliasing is supported, but no longer required by the framework. The only purpose of aliasing is to resolve conflicts between columns of the same name in different tables through a join construct. Since the framework now uses the column index java.sql.ResultSet accessor methods rather than the column name methods, aliasing is no longer necessary. The usage of column indexes rather than column names for java.sql.ResultSet accessors also provides a slight performance increase.
Sybase. JRF now correctly supports Sybase. SQLServerSybaseDatabasePolicy has been renamed to SQLServerDatabasePolicy.
Firebird. JRF now supports Firebird.
PersistentObject.getEncodedKey(). A method now exists on PersistentObject to return the encoded key of the object (e.g. the same value that would be returned by AbstractDomain.encodePrimaryKey(). This method was added to support application's need of using the keys without instantiating or using an AbstractDomain implementation. Code generators provided will generated the code for this method.

Speed Enhancements

Considerable effort was undertaken to make JRF an effective server utility for high speed transaction processing. The author of these enhancements gained considerable experience in the past by suffering through the task of forcing server applications to meet sub-second response times. The ideas from that experience have been applied to the JRF framework.

Changes to enhance speed include:

Reflection optimization and elimination. Using reflection to translate from PersistentObject to SQL constructs and vice versa was a considerable performance detractor. Applications that use this version of JRF may either use the reflection optimization code or eliminate reflection altogether. An interface called GetterSetter contains methods to get a particular attribute value from a PersistentObject and conversely set an attribute in the PersistentObject. Each instance of ColumnSpec contains an implementation of GetterSetter. Manually writing such implementations is of course utterly impractical. A simple code generator exists to generate implementations for a particular instance of PersisentObject. (see net.sf.jrf.codegen.GetterSetterBuilder). In fact, existing applications can use the generator to construct implementations and AbstractDomain will automatically use these implementations without any application code changes.
PreparedStatement usage. AbstractDomain now exclusively uses java.sql.PreparedStatements to save, delete and fetch by primary key value; static SQL is restricted to ad-hoc queries (e.g. findWhereOrderBy()). Consistent use of static SQL detracts from performance on two levels. First, the SQL strings doing standard operations of save and delete must be re-built every time, iterating through the list of column specifications and making decisions on the requirements of those specifications. Second, many database engines such as Oracle and Sybase support a 'parse-once-execute-many' concept where parameterized SQL is parsed only once and executed numerous times. For such databases, the performance boost of using prepared statements is considerable. Using prepared statements in domains poises the JRF framework to properly handle the JDBC Version 3.0 functionality of pooled prepared statements (See specification for JDBC Version 3.0 on the Sun website).
Dedicated Connections. An application may mark an AbstractDomain instance to use a dedicated connection thus persisting any prepared statements to the connection. Once JDBC Version 3.0 statement pooling is in place, using dedicated connections will probably not be necessary.
Object persistence in AbstractDomain. Some of the more "heavy-weight" objects in AbstractDomain are now built only once and reused (for example the SQLSelectBuilder instance). From a larger perspective, AbstractDomain sub-classes themselves have always been rather heavy-weight objects with considerable constructor overhead cost. With the addition of more features, they are even more heavy-weight. However, if instantiated once in the constructor of some service class, performance should not suffer. For example the following:
```
		 public class MyService {
			private DomainOne domain1;
			private DomainTwo domain2;
		
			public MyService() {
				domain1 = new DomainOne();
				domain2 = new DomainTwo();
			}	
			public PersistentObject findSomethingOne(String data) {
				return domain1.find(data);	
			}
		
```
is preferable to:
```
		 public class MyService {
			public MyService() {
			}	
			public PersistentObject findSomethingOne(String data) {
				return new DomainOne().find(data);	
			}
		
```
Applications should generally either pool a service with wrapped domains or pool the domains themselves.
Duplicate Key Error Handling. In previous versions, the methodology used to check for duplicate key insertions was to "pre-select" by key on the table before insert (see AbstractDomain.validate()). While this methodology still exists, an alternative faster way of handling duplicate keys has been introduced. Most commercial database vendors return a specific error code for duplicate key inserts. A DatabasePolicy method has been added to return this value. AbstractDomain will now check the error code of SQLException and return the existing DuplicateRowException for duplicate key insert operations (e.g. save()). For database vendors that do not supply error codes, specific error text can be specified in the DatabasePolicy to implement duplicate key error handling. For example, from Postgres:
```
		 public String getDuplicateKeyErrorText() {
			return "Cannot insert a duplicate key into unique index"; 
	 	 } 
		
```

Architectural Changes

The Architectural changes fall into two areas: connection management overhaul and the introduction of embedded PersistentObject support in AbtractDomain.

Connection Management Overhaul

The management of connections in the JRF framework is considerably different from previous versions. The most dramatic change is the elimination of the JDBCHelper class. JDBCHelper is bit of a catch-all, non-object-oriented utility class. It handled connections, pooling (with JDBCHelperPool), statement execution and result set management. While useful for general utilities, it becomes up a bit unwieldy when used with AbstractDomain leads to such limitations as lack of handling multiple result sets.

The SQL management and database connection functionality of JDBCHelper has been broken into smaller classes and pooling now is reserved only to implementations of javax.sql.DataSource or javax.sql.ConnectionPoolDataSource. The JRF framework now contains a default implementation of javax.sql.ConnectionPoolDataSource. Applications may use this implementation or one of the many commercial or open source versions that exist. The design approach for the new connection management was to center on the needs of AbstractDomain. A class called JRFConnection encapsulates connection information in JRF in this version. An AbstractDomain sub-class will contain a single instance of this class. Unlike previous versions, applications have no direct control over the setting the connection handling for AbstractDomains. Rather, applications have indirect control over the connection mechanism through one of three ways (this text is replicated in the javadocs for AbstractDomain):

An application does not call any method on the domain to set up connection handling. When a connection to the database is required by the domain, the no-argument version JRFConnectionFactory.create() will instantiate a JRFConnection instance based on the JRF system Properties instance. This way of handling connections should suit the majority of applications.
An application explicitly sets the connection Properties instance to use for creating a JRFConnection instance via a call to AbstractDomain.setProperties(). The domain will then use the JRFConnectionFactory.create(Properties) version to obtain a JRFConnection instance. This factory method will use whatever properties exist in the supplied argument and fallback on the JRF system Properties for any property value it does not find. See the documentation for JRFConnectionFactory for more details on this behavior.
An application may set a DataSource instance to use via a call to setDataSource. This methodology will suit applications where properties to instantiate a DataSource are not known at program start up. For example, an application server may receive a message with the requisite parameters for obtaining a DataSource through JNDI.

Transaction Management

The handling of transactions in this version is considerably different from previous versions. For a single AbstractDomain instance the transaction handling is automatic (much in the way it was before except that now transactions including embedded objects are supported - see Embedded Persistent Objects). For applications that wish to support transactions using multiple domains, the approach has been streamlined. Previously, a multiple domain manual transaction was implemented rather indirectly:

	JDBCHelper helper;
	ADomain domainA;
	BDomain domainB;
	.
	.
	domainA.setJDBCHelper(helper);
	domainB.setJDBCHelper(helper);
	try {
		domainA.beginTransaction(); // Both use same JDBCHelper
		.
		// set some values.
		domainA.save(...);
		//etc.
	}
	catch ( ....
	//etc.

The approach for multiple domains for this version is to use a class called JRFWriteTransacton:

	ADomain domainA ;
	BDomain domainB;
	JRFWriteTransaction wt = new JRFWriteTransaction();
	.
	.
	MyConstructor() {
		wt.addDomain(domainA);
		wt.addDomain(domainB);
		.
		.
	}
	.
	.
	.
	wt.beginTransaction();
	try {
		// set some values.
		domainA.save(...);
		//etc.
	}
	catch (Exception ex) {
		wt.abortTransaction();
	}
	wt.endTransaction();

In the previous version both domains had to use the same connection. In this version connection management is of no concern to the application; domainA could point to Sybase and domainB could point to Oracle.

Embedded Persistent Objects

In previous versions, support for embedded PersistentObjects in AbstractDomain was implicit. A user could populate embedded fields and objects by implementing the suite of protected methods that have no implementation in the base class ( (e.g. preSave(),postValidate(),postFind()).

This version now explicitly handles the "pieces". The protected methods are still supported, but an application can move away from these methods to handle embedded PersistentObjects by implementing a class called EmbeddedPersistentObjectHandler. Since a single save operation may update many embedded objects, a new PersistentState of DeletedPersistentState was added. By using this state, an application can pass a complex object graph back to the domain to have only portions of the object deleted. See EmbeddedPersistentObjectHandler and AbstractDomain javadocs for more information.

Use the code generator EmbeddedGenerator to generate the embedded objects.

Code Generation

Complete documentation for the code generators is forthcoming. The following preliminary guide is provided until a formal document can be written.

Basic Overview

Examine DTD files and documentation in source/org/vmguys/dtd.
Examine test/source/xml properties files, which are documented.
Examine the test/source/xml xml example files used for the JUNIT tests.

Setting Up

Examine the log4j.properties file in test/source/xml. Note the designation of "genlogs" directory.
Examine build.xml target "generateFromXML". Note how the instructions here match the properties files:
- "genlogs" directory is created for logging
- Package directories are created.
- The DTD files are copied into the xml directory so the parser can find them.
- Two arguments are the same for both generators: the first is the properties file and the second is the XML file.

Abstract Base Generator

All generators sub-class org.vmguys.appgen.Generator. Examine the protected constructor in this file which does the following:

Parses the XML file and sets up protected instance variables to the document.
Reads the properties file and calls the appropriate setter methods for each parameter in the file (e.g. "SourceOutputDbObj=srcgenerated/testgen/base" in the file is converted to this.setSourceOutputDbObj("srcgenerated/testgen/base") in the class.

There is a static class name variable in this base file so that only one "main()" method is required for any generator (pattern of evocation is always "java X propertiesfile xmlfile")

Template Basics

One of the primitive concepts of the code generator is the use of templates with markers tokens to distinguish the variables. For example:

private static final String classTemplate = 
	"public class $classNameObj$ extends PersistentObject $interfaces$ {\n"+
	.
	.

The two tokens enclosed in the "$" would be replaced in the generated code might be:

	public class Name extends PersistentObject implements PersonEntity {
	.
	.

Generator Basic Concepts

For each XML element defined in the DTD, there is a corresponding java class that subclasses the abstract class org.vmguys.appgen.SourceGenXMLEntity. At a minimum, this class contains a hash map of all element attributes. Sub-classes may also have some setter methods if desired. To handle these classes, a meta data class exists called org.vmguys.appgen.SourceGenXMLEntityMetaData. It is in this class the all the magic happens. The generators build a hierarchy of these meta classes and call a single static method to map the contents of the parsed XML document into a tree of


SourceGenXMLEntity

nodes. Examine the static method createEntityTreeFromXML(). For each element, the hash map of element attributes is filled, any setter methods are invoked (XMLReadHandler.elementToObject()) and finally, an abstract method implementation (resolveImpliedKeys()) is called to allow the SourceGenXMLEntity sub-class to sort out any issues with "implied" elements.

To see a simple example of the tree creation process, examine the constructor of BaseGenerator.java. For a complex example, examine the constructor of EmbeddedGenerator.java. One of the key concepts here is that the constructors will instantiate the SourceGenXMLEntity sub-classes for table, column and so forth from names specified in the properties files. If no names are specified the default base versions are used. You can sub-class these base versions to perform all sorts of tricks specific to an application.

Sub-classing the Generators

In combination with sub-classing the XMLEntity classes, you sub-class both generators and implement the protected methods to provide additional functionality. Examine the protected methods and their context in both BaseGenerator.java and EmbeddedGenerator.java.

Common Techiques

One of the more common techniques to use in the code generator is to generate implementations of methods based on whether the objects implement certain interfaces. Comma-separated lists of interfaces are part of the base DTD. If you sub-class the generator, you may accomplish this generation with some like:


	/** Allows a sub-class to add additional code for embedded object AbstractDomain.
	 * @param current current CompositeObjectXMLEntity.
	* @return any additional code to place at the end of generated AbstractDomain.
	*/
	public String getAdditionalDomainCode(CompositeObjectXMLEntity current) {
		String interfaces = current.getTransientKeys().get("interfaces");
		if (interfaces.indexOf("PersonEntity") != -1) { 
			return "	public void preValidate( ... 
		}
	}

The above example suggests a different approach providing implementations of the protected AbstractDomain methods. Rather than manually implementing these methods, let the code generator handle this task.

Modifying Existing Code with JDBCHelper Arguments

postFind(). Modify all implementations to the following signature:
```
		protected void postFind(PersistentObject aPO,JRFResultSet baseFindResultSet)
	
```
JRFResultSet has all the methods that JDBCHelper has to obtain result set data so all you need to do is change the signature. If you have to execute a query here use:
```
		JRFResultSet other = this.getJRFConnection().getStatementExecuter().executeQuery(" ....");
	
```

preValidatate(),preSave() etc. Modify all with the following signatures:

	protected void preValidate(PersistentObject aPO, StatementExecuter stmtExecuter)
	protected void preSave(PersistentObject aPO, StatementExecuter stmtExecuter)
	protected void postSave(PersistentObject aPO, StatementExecuter stmtExecuter)
	protected void preDelete(PersistentObject aPO, StatementExecuter stmtExecuter)
	protected void postDelete(PersistentObject aPO, StatementExecuter stmtExecuter)

You can use StatementExecuter to process any SQL statement. Furthermore, you many process as many result sets as you choose.

Eliminate all calls to getJDBCHelper and setJDBCHelper; they will generate runtime exceptions.
protected int executeSQLUpdate(String sql, JDBCHelper aJDBCHelper) will still work but the helper argument will be ignored.
protected void executeSQLQuery(String sql, RowHandler aRowHandler, JDBCHelper aJDBCHelper) will work but the helper argument will be ignored.
All of the find...(X, JDBCHelper) methods will work but the helper argument will be ignored.
All of overloads of these methods with JDBCHelper will work but the JDBCHelper argument will be ignored: save(),delete(),validate(),findLong(),findInteger(),findTimestamp().
All versions of beginTransaction and endTransaction now do nothing.
If you have implemented the protected RowHandler interface, the signature for the single method is now:
```
	public void handleRow(JRFResultSet resultSet)
	
```

Miscellaneous Code Changes

Modify all timestamped optimistic lock columns from TimestampColumnSpec to TimestampColumnSpecDbGen.
AbstractStaticDomain is now deprecated. The same functionality exists by using AbstractDomain and calling setCacheAll(true).
Since there is no longer a single instance of DatabasePolicy, the method public static DatabasePolicy getDatabasePolicy() is no longer supported. If you need to obtain the default DatabasePolicy instance, do the following:
```
	JRFConnection conn = JRFConnectionFactory.create();
	DatabasePolicy policy = conn.getDatabasePolicy();
	
```
Encoding compound primary keys now uses StreamTokenizer instead of StringTokenizer to format the encoded string. If your code manually examines this key, you will have to make changes:
```
	Old version:  1|MFG
	New version:  1|"MFG"
	
```
StreamTokenizer is used so that quotes and bars ('|') may be embedded in a String key value.

Short-term TO DO List

Fix incorrect and incomplete DatabasePolicy implementation methods.
Create new DBtype-Readme (e.g. postgres-readMe.txt) files for each database type supported.
Expand CompositeTEST.java with more tests.
Test EJB example directory.
Clean up documentation in jrf.properties.
Update existing user guide documentation.
Generate a skeletal XML file from reading the database schema.
Expand CacheTEST.java with more tests.
Full testing and potential changes to BLOB and CLOB column specifications.
Clean-up of all javadoc. Minimally, the following needs to be done:
- Class description for AbstractColumnSpec.
GenerateDatabase has been successfully run on only Postgres and MySql. Other databases need to be tested. DatabasePolicy methods for obtaining create index formats may need to be abandoned.
Documentation for XML creation.
Add policy method to get SQL for dropping sequences.