Objective database abstraction layer (ODAL) is a high-performance multi-purpose (see below) database manipulation framework. Features include query API, O-R mapping, data validation/conversion, stored procedure support, code generation.

Main focus of the project is to create maintainable, flexible, fast and scalable database abstraction layer with a convenient and simple API. These goals are achieved by minimizing manual work required to create and maintain the database access layer and consistently applying “separation of concerns” principle. ODAL generates code whenever it is possible out of the database metadata because in the vast majority of projects the database is a given and invariable part created with a different set of tools. The framework metadata descriptors are the source for code generation of persistent objects, validators, convertors, optionally object trees and its factories. The metadata descriptors, in its turn, are also generated from any JDBC compliant database using provided tools.

Separating the descriptors and the persistent classes into modifiable and non-modifiable by hand, ODAL achieves ability to propagate database changes to the application by simply regenerating code. Persistent objects are divided into basic and composite ones that provides for gradual growth of the application complexity. ODAL persistent objects are equipped with serialization mechanism that allows objects to be updated on remote machine and their changes saved locally with no synchronization with a database. ODAL XML serialization streams allow to serialize persistent objects in XML format. ODAL persistent objects do not need to be aware of session to keep track of changes which makes them appropriate in REST type applications.

ODAL differentiates between Domain and Persistent Objects. In some simple cases they can be the same thing. In more complicated ones, when the database does not reflect closely the business domain, they should be different, and the the mapping should rather be done in code than through any other means since it is much easier to maintain pure Java than, let us say, XML.

In general ODAL does not deal with Domain Model directly. We concentrate on the Persistent Objects. ODAL supports 2 approaches.

In Model 1 approach, the Persistent Objects are generated and the application objects (that in in some cases may be your Domain ones) are derived from them.

In Model 2 approach, the Persistent Objects and the Java POJOs with the same structure are generated and the application objects (that in in some cases may be your Domain ones) are derived from the corresponding POJOs.

Conceptually, ODALs' Model 1 is closer to SDO DAS than to a traditional ORM mapper. ODAL Persistent Objects keep their changes within them allowing for detached and remote updates. ODAL's PersistentObject combines features of SDO DataObject and DataGraph. Important difference is that PersistentObject does not expose any methods that can be interpreted as those of Java Bean. That allows the derived classes to freely implement any Java Bean properties with guaranteed no clash with those of PersistentObject. ODAL also serves as a Data Access Service. ODAL can be used as base of an SDO provider.

Performance of the framework is always close to that of pure JDBC. ODAL performs well in both interactive and batch oriented applications (this is referred here as “multi-purpose”).

ODAL provides some advanced caching options one of which is multi-index cache allowing to retrieve object by different keys. Another one is transaction sensitive cache which synchronizes cache removals with transaction commits allowing, among others, for consistency of distributed caches. Caching in ODAL is controlled dynamically. ODAL also provides means to minimize cached objects memory footprint.

Code generation tools allow for generating beans out of database tables, ad-hoc queries and even multi result set stored procedures.

At runtime, only the compiled code is used The metadata descriptors are only employed at the code generation stage. With Model 1 approach neither reflection nor byte code manipulation is used.

POJO beans generated (or built manually) with Model 2 are real POJOs meaning that there is no dependency on specific annotations, and no byte code manipulation or proxies required.

With both Model 1 and Model 2 ODAL supports advanced Query API with sophisticated Query By Example approach based on the generated Persistent Objects. Query Tree mechanism allows to dynamically “re-wire” predefined configuration of Persistent Object trees. Query trees are serializable into SDL string format which allows for saving dynamically created searches/reports or executing query trees remotely.

ODAL queries are structures rather than strings allowing for modification of its parts, WHERE clause only, for instance.

ODAL is optimized for using with large result sets and batch processing. It has continuous paginated queries, data pipes allowing to write to multiple destinations.

Query context (that can be optionally disabled) allows for correct object instances resolution within one query tree (or select retrieval) rather than one transaction. This limits memory usage for large result sets. Query context use may be also completely disabled.

ODAL has minimal dependencies on other libraries. In fact, all the dependencies at runtime are optional except for the JDBC drivers.

Since ODAL does not use any XML or other type descriptors at runtime, its startup time is very short.

Tested with Java 1.4, 1.5 and 1.6.

Java and the Java Coffee Cup Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.