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.
Difference between revisions of "EclipseLink/Development/DBWS/ImprovedDataDictionaryQueries"
(→Options) |
(→Options) |
||
| Line 36: | Line 36: | ||
=== Options === | === Options === | ||
| − | # create a new optional bundle (similar to the existing EclipseLink bundles for ASM and ANTLR) containing all Database Metadata Model classes <br>refactored to provide capabilities for both runtime and utilities. This would mean, for example, that EclipseLink runtime users that do not require <br>DDL creation would not require the additional bundle; similarly, EclipseLink runtime users that do not use <br><tt>o.e.p.platform.database.oracle.plsql.PLSQLrecord</tt> would not require the new bundle. For users of the <tt>DBWSBuilder</tt> utility, the new <br>bundle would not be <i>mandatory</i> in an OSGi-sense, but the bundle - which is after all just a <tt>.jar</tt>-file - would be required on the classpath in addition to the <br><tt>eclipselink.jar</tt> and the other required <tt>.jar</tt>-files pertaining to Web services development (javax.wsdl, javax.activation, javax.xml.soap jars) | + | # create a new optional bundle (similar to the existing EclipseLink bundles for ASM and ANTLR) containing all Database Metadata Model classes <br>refactored to provide capabilities for both runtime and utilities. This would mean, for example, that EclipseLink runtime users that do not require <br>DDL creation would not require the additional bundle; similarly, EclipseLink runtime users that do not use <br><tt>o.e.p.platform.database.oracle.plsql.PLSQLrecord</tt> would not require the new bundle. For users of the <tt>DBWSBuilder</tt> utility, the new <br>bundle would not be <i>mandatory</i> in an OSGi-sense, but the bundle - which is after all just a <tt>.jar</tt>-file - would be required on the classpath in addition to the <br><tt>eclipselink.jar</tt> and the other required <tt>.jar</tt>-files pertaining to Web services development (javax.wsdl, javax.activation, javax.xml.soap jars) <br><br>This options would the first two issues, but now the third |
# refactor | # refactor | ||
Revision as of 11: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:
- 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 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
- 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 options would the first two issues, but now the third - refactor