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

Revision as of 11:23, 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 driver issues can be found here.

Database Metadata Model Objects Refactoring

Database metadata is represented by Java model objects. In EclipseLink, these model classes are spread across several packages and components:

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

In addition to the above classes not being sufficient for the requirements of the DBWSBuilder utility, there are issues:

• code duplication: for example, 3 different classes describe Database tables
• limited or no code reuse: no common class/interface to extend/implement
• OSGi packaging restrictions: any revision of the class hierarchy structure must obey the rules w.r.t. split packages
• violation of DRY (Don't Repeat Yourself) Principle: existing Eclipse DTP ModelBase sub-project solves the identical problem

Options

1. Create a new optional bundle (similar to the existing EclipseLink bundles for ASM and ANTLR) containing all Database Metadata Model classes
   refactored to provide capabilities for both runtime and utilities. 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.PLSQLrecord 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)
   This option would solve the first three issues, but not the fourth.
   
2. Refactor all Database Metadata Model classes to provide capabilities for both runtime and utilities, keeping the classes in the EclipseLink core bundle.
   This option is similar to (1) above in that it only solves three issues, but in addition, 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 options would solve all four issues identified above; however, there is still one 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 four issues identified above.