Difference between revisions of "EclipseLink/Development/DBWS/ImprovedDataDictionaryQueries"

Revision as of 13:26, 25 September 2008

DBWS Improved DataDictionary Queries

Document History

DBWS utility enhancement: Improved DataDictionary Queries

Motivation

bug 234681
The key for the DBWSBuilder to support multiple database platforms (Oracle, DB2, Sybase, MS SQLServer, etc.) lies in the ability to extract meta-data for Stored Procedures and Tables from the database. The standard JDBC meta-data APIs (available through the java.sql.DatabaseMetaData interface) unfortunately is not fully implemented across vendors, nor in a standard fashion. For example, the simple act of getting the names of available databases is different across platforms: on Oracle the getSchemas() method is used while for DB2/Sybase/MS SQLServer the getCatalogs() method is used. Another example of cross-platform meta-data issues is the getColumns method: for PostgreSQL, the name of the table must be lower-case; for Oracle, it must be upper-case; others support mixed-case. A case-study found here expands on these issues and a list of outstanding JDBC issues can be found here.

Database Metadata Model Refactoring

In EclipseLink, the Database Metadata Model classes are spread across several packages and components:

• o.e.p.internal.helper - DatabaseType, DatabaseTable, DatabaseField
• o.e.p.tools.schemaframework - TableDefinition, FieldDefinition, TypeDefinition
• o.e.p.platform.database.oracle.plsql - PLSQLrecord, PLSQLargument, OraclePLSQLTypes
• (in Utils component) o.e.p.tools.dbws.jdbc - DbTable, DbColumn, DbStoredProcedure

In addition to the above classes not being sufficient for the improved DataDictionary Queries requirements of the DBWSBuilder utility,
they violate the DRY (Don't Repeat Yourself) Principle: an existing Eclipse DTP ModelBase sub-project solves the identical problem.

Currently, the EclipseLink Database Metadata Model classes suffer from code duplication (i.e. 3 different classes describing Database tables),
and has little-to-no code reuse (i.e. no common class/interface to extend/implement).

Options

1. Refactor all Database Metadata Model classes to provide capabilities for both runtime and utilities and create a new optional bundle (similar to the existing
   EclipseLink bundles for ASM and ANTLR). This would mean, for example, that EclipseLink runtime users that do not require DDL creation would not require
   the additional bundle; similarly, EclipseLink runtime users that do not use o.e.p.platform.database.oracle.plsql.* would not require the new bundle.
   For users of the DBWSBuilder utility, the new bundle would not be mandatory in an OSGi-sense, but the bundle - which is after all just a .jar-file - would be
   required on the classpath in addition to the eclipselink.jar and the other required .jar-files pertaining to Web services development (javax.wsdl,
   javax.activation, javax.xml.soap jars) and the JDBC driver jar(s).
   
   This option would eliminate internal code duplication and provide for code-reuse, but it does not address the DRY-issues raised by the DTP ModelBase.
   
   
2. Same as (1), but keep the Database Metadata Model classes in the EclipseLink core bundle.
   
   Similar to (1), this option solves some issues but the EclipseLink core bundle would contain classes that no user requires at runtime.
   
   
3. Refactor the EclipseLink core bundle and the DBWSBuilder utility to use the DTP ModelBase bundle.
   
   This option would solve all three issues identified above; however, there is an outstanding question - is the DTP ModelBase suitable for use at runtime?
   I have asked the DTP PMC precisely this question.
   
   
4. Status quo - create/extend existing classes in o.e.p.tools.dbws to satisfy the requirements of the DBWSBuilder utility.
   
   This option would solve none of the three issues identified above.