Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

(Motivation)
(Database Metadata Model Objects Refactoring)
Line 30: Line 30:
  
 
In addition to the above classes not being sufficient for DBWSBuilder's needs, there are some issues:
 
In addition to the above classes not being sufficient for DBWSBuilder's needs, there are some issues:
* code duplication: 3 different classes describe Database tables
+
* code duplication: for example, 3 different classes describe Database tables
* limited or no code reuse: no common base class/interface to extend of implement
+
* limited or no code reuse: no common class/interface to extend/implement
* OSGi split-packaging restriction: any revision of class hierarchy structure is 'tricky'
+
* OSGi packaging restriction: 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 ===
 
=== Options ===

Revision as of 10:08, 25 September 2008

DBWS Improved DataDictionary Queries

Document History

Date Author Version Description & Notes
080922 Mike Norman 1.0

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 DBWSBuilder's needs, there are some 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 restriction: 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

Back to the top