Tornado Object-Relational Mapping Engine

Overview
Features
Build
Configuration
Download
Project Info

Overview

This is preliminary documentation for the Tornado Object-Relational Mapping Engine. The engine is still very much a work in progress. However, it already provides some potentially useful functionality depending on the project requirements. An earlier version of this library has been supporting a commercial transaction processing application for almost a year. This application had been implemented using Objectivity D/B and was converted to Oracle with very minimal application changes. The library also provides the object mapping layer for the open source XPlanner project -- a planning support tool for Xtreme Programming teams.

Features

The engine is intended to be a compact, fast mapping engine for Java objects. Although the jar file is small (currently < 55 KB!), Tornado supports the following features...

  • XML-based configuration (similar to Castor's configuration format)
  • No requirement to inherit from persistence-related base class
  • Inheritance
    • Multiple table
    • Single-table "polymorphism"
  • Supports MySQL and Oracle
  • Compound or simple keys
  • Object caching
  • Simple pessimistic locking ("select for update")
  • Relationship support
    • Many-to-many
    • One-to-many
    • Lazy-loaded
  • Virtual "delete" - objects can be marked for delete instead of physically deleted from the DB.
  • Automatic "last update" object time stamping
  • Direct access to SQL
  • Automatic identity-based query generation (for loading single objects)
  • "Plug-in" capability for identity extraction, generation, and mapped class selection.
  • Access to private fields and methods
  • JUnit-based unit tests

New in version 0.3!

  • Virtual event listeners - allows persistent beans to be event listeners/producers
  • Transaction listeners (triggers before/after insert, update, delete, ...)
  • JSP Tags for using persistent beans

Some of these "features" will probably be somewhat controversial. For example, when using other mapping engines, I have found the proprietary and/or object-oriented query languages often do not have the expressive power for efficiently performing the queries I need. Tornado is a thin layer above SQL so it's relatively easy to write object queries that do joins or use advanced SQL features.

Similarly, the access to private fields and methods is often considered a bad practice. Although I wouldn't recommend abusing this feature, sometimes it's the only way to provide O/R mapping for legacy objects without significantly modifying them. Tornado will attempt to use public methods rather than use private variables, if possible.
tornado-db@sourceforge.net

SourceForge Logo