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.
EclipseLink/Development/DBWS/ImprovedDataDictionaryQueries
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:
- 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 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