XORM persists data corresponding to abstract methods and interface
methods that follow standard Java bean naming conventions. For
traditional data objects (objects without custom behavior), you can
provide only a Java interface and let XORM do the work of implementing
No Compile-Time Enhancement or Source Code Generation
XORM does not require any preprocessing of source files or bytecode
class files. This means no extra Ant tasks and messy development
XORM uses the standard JDO 1.0 API. XORM-specific classes need only
be referenced for factory methods to acquire new persistent object
instances. Some JDO methods are not yet implemented.
JDO Query Language
XORM uses JDOQL as its default query mechanism, so developers can use
a Java-like syntax, including Java class and field names. Some JDOQL
features are not yet implemented.
Reverse Engineering of JDO Metadata
An Ant task will read in all the classes and interfaces in a package
and create a JDO metadata for you to add mapping information to.
Mapping to Existing Tables
XORM is designed to integrate with an existing relational database. It does not create or require any special tables or columns.
Mapping to Read-Only Columns
XORM can be configured to treat certain database columns as read-only,
ensuring that those columns will never be included in update or insert
XORM support mapping foreign keys to an object to create collections.
XORM supports mapping object references to foreign key columns.
XORM supports using a join table for collection references.
Reverse Engineering of Database Schema XML
XORM comes with Ant tasks to generate the required database schema XML
file. This human-readable file can be edited by hand or regenerated
to capture further updates to a schema.
Integration with Primary Key Generation
XORM can use autoincrement facilities of SQL databases or sequences
for primary key generation.
Use of Prepared Statements
XORM uses JDBC Prepared Statements wherever possible, allowing JDBC
drivers to optimize database access accordingly.
Lazy Loading of Object Instances
XORM loads only the objects you need at runtime, subject to
configurable default fetch group settings. By default, object
references use lazy loading. If certain references are commonly
traversed, you can indicate this in the JDO metadata file, and XORM
will issue optimized SQL join or outer join queries to prefetch the
Partial Loading of Object Instances
Based on settings in the JDO metadata, XORM will load by default only
the fields of your objects that are specified. Access to other fields
will cause additional SQL statements to be issued, but may improve
performance for large data fields.
Lazy Loading of Collections
Collections are also lazy loaded by default.
Optimized Size Queries
Invoking the size() method on a persistent object Collection will
result in a SQL count(*) statement if the collection has not yet been
Minimal Object Updates
XORM will only update objects whose values change during a
transaction, and will only update the particular columns of the
database rows which change.
Optimized Many-to-Many Updates
XORM generates incremental updates to many-to-many mapping tables,
instead of rewriting all entries for a given object whenever the
Factory-level Object Cache
The factory-level object cache is enabled by default. All data read
from the database goes into the cache so that multiple lookups of the
same object are reduced to a single SQL query. The cache can be
disabled for applications with multiple instances writing to the
XORM has built in connection pooling that works with any JDBC driver.
The pool can be configured to automatically check for bad connections
and recover in many situations.
Custom SQL Queries
XORM allows developers to use raw SQL in areas where queries cannot be
expressed in JDOQL.
Extensible Datastore Support
XORM's datatore architecture allows heterogeneous datastores to be
accessed through a common API. Support for most standard SQL
databases is usually trivial; support for custom storage APIs and
integration with third-party products is straightforward.
Customizable Fetch Groups
Fetch groups that control which data will be prefetched can be
determined at runtime by extending XORM's fetch group manager.
Customizable Factory-Level Data Cache
XORM's extensible cache API allows the default implementation, which
uses SoftReferences, to be replaced or extended by other cache
Extensible Query Support
XORM's query API allows developers to provide alternate query
languages, including the possibility of object-oriented query