A JDO implementation can select its own persistence platform. It can persist to files for example, or to ODBMS, or to RDBMS, or OLAP. JPOX currently persists to RDBMS platforms.
JPOX supports a range of RDBMS. The reason for the support of specific RDBMS rather than all is that SQL is not standard across RDBMS and so the calling layer has to implement RDBMS-specific features in its approach. To give an example of this non-standard syntax many RDBMS use the syntax
DROP TABLE 'table_name' CASCADE
for dropping tables. Unfortunately Sybase doesn't support the CASCADE facility and instead uses
The support of RDBMS in JPOX revolves around an AdapterManager class. This manages the support for RDBMS in JPOX and provides a register method addAdapter where you can specify that if the RDBMS product name contains a particular substring, then use this adapter. The individual adapters for RDBMS are provided by subclasses of DatabaseAdapter. This provides the interface to be implemented for adapters for individual RDBMS. The base DatabaseAdapter additionally provides a default implementation attempting to provide good defaults for the majority of RDBMS. Where a particular RDBMS differs from this default, a separate adapter class is needed.
The following diagram shows the relationships between various classes involved in the adapter process. It demonstrates the use of adapters for databases like MySQL which implements methods for MySQL that differ from the default adapter.
Adding support for a particular RDBMS involves overriding the base DatabaseAdapter class. You only need to override the methods that differ. The differences can be in things like the basic SQL syntax for a command, or they can be in the use of FCO mapping types if your RDBMS needs something particular to its operation. For example, the Oracle adapter provides its own CLOB type mapping.
We plan to extend the JPOX implementation in the future to allow addition of RDBMS Adapter "plugins", so that users can supply JAR's supporting their own RDBMS, allowing flexible extension rather than wait for the support for an RDBMS to be added officially to JPOX. This would revolve around the DatabaseAdapter, with developers extending the DatabaseAdapter "default" adapter, adding on handling for specific features. The current structure will easily allow this since the AdapterManager class provides an addAdapter method already, and it would simply be a matter of adding a user-wrapper around that.
JPOX has TypeInfo classes holding metadata information about the database data types. This information is collected from the database, for
most of the data types via java.sql.DatabaseMetaData. This information includes precision, type name, scale, etc.
In theory, this mechanism should provide enough information to allow generating, validating and managing the database schema, however,
in practice some databases do not provide accurate information about the data types or are not returned by java.sql.DatabaseMetaData.
It's very usual for proprietary database data types to not be returned by java.sql.DatabaseMetaData.
For non provided data types, a DatastoreAdapter may implement the operation createTypeInfo(DatabaseMetaData metadata) allowing to define the
data types that are missing.
Finally, for non accurate data types, a database adapter may extend the TypeInfo class to fix the wrong metadata.
