|
|
(23 intermediate revisions by the same user not shown) |
Line 12: |
Line 12: |
| | Mike Norman | | | Mike Norman |
| | 1.0 | | | 1.0 |
| + | |- |
| + | | 081130 |
| + | | Mike Norman |
| + | | 2.0 - use JPub to get metadata |
| |} | | |} |
| | | |
| == DBWS utility enhancement: Improved DataDictionary Queries == | | == DBWS utility enhancement: Improved DataDictionary Queries == |
− | | + | With the decision to use a stripped-down version of JPub to get database metadata, [https://bugs.eclipse.org/bugs/show_bug.cgi?id=234681 bug 234681 ] |
− | === Motivation ===
| + | changes from <br /> 'Improve DBWSBuilder utility's use of database metadata to support more auto-generated cases' to <br /> |
− | | + | 'DBWSBuilder utility auto-generate XR artifacts for complex PL/SQL arguments' |
− | [https://bugs.eclipse.org/bugs/show_bug.cgi?id=234681 bug 234681 ] <br/> | + | |
− | 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 <b><code>java.sql.DatabaseMetaData</code></b> interface) unfortunately is not fully implemented across vendors, nor in a standard fashion.
| + | |
− | For example, the simple act of getting the <b><i>names</i></b> of available databases is different across platforms: on Oracle the <b><code>getSchemas()</code></b> method is used while for DB2/Sybase/MS SQLServer the <b><code>getCatalogs()</code></b> method is used. Another example of cross-platform meta-data issues is the <b><code>getColumns</code></b> method: for PostgreSQL, the name of the table <u>must</u> be lower-case; for Oracle, it <u>must</u> be upper-case; others support mixed-case. A case-study found [http://www.sun.com/bigadmin/content/submitted/jdbc_drivers.html here] expands on these issues and a list of outstanding JDBC issues can be found [[EclipseLink/Development/DBWS/ImprovedDataDictionaryQueries/OutstandingJDBCIssues|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:
| + | |
− | * <tt>o.e.p.internal.helper</tt> - <tt>DatabaseType</tt>, <tt>DatabaseTable</tt>, <tt>DatabaseField</tt>
| + | |
− | * <tt>o.e.p.tools.schemaframework</tt> - <tt>TableDefinition</tt>, <tt>FieldDefinition</tt>, <tt>TypeDefinition</tt>
| + | |
− | * <tt>o.e.p.platform.database.oracle.plsql</tt> - <tt>PLSQLrecord</tt>, <tt>PLSQLargument</tt>, <tt>OraclePLSQLTypes</tt>
| + | |
− | * (in Utils component) <tt>o.e.p.tools.dbws.jdbc</tt> - <tt>DbTable</tt>, <tt>DbColumn</tt>, <tt>DbStoredProcedure</tt>
| + | |
− | | + | |
− | In addition to the above classes not being sufficient for the requirements of the <tt>DBWSBuilder</tt> utility, there are issues:
| + | |
− | # code duplication: for example, 3 different classes describe Database tables
| + | |
− | # 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 <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 <tt>o.e.p.platform.database.oracle.plsql.*</tt><br> would not require the new bundle. For users of the <tt>DBWSBuilder</tt> utility, the new bundle would not be <i>mandatory</i> in an OSGi-sense, but the bundle - <br>which is after all just a <tt>.jar</tt>-file - would be required on the classpath in addition to the <tt>eclipselink.jar</tt> and the other required <tt>.jar</tt>-files pertaining <br>to Web services development (javax.wsdl, javax.activation, javax.xml.soap jars) <br><br>This option would solve the first three issues, but not the fourth.
| + | |
− | # Refactor all Database Metadata Model classes to provide capabilities for both runtime and utilities, keeping the classes in the EclipseLink core bundle. <br><br>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.
| + | |
− | # Refactor the EclipseLink core bundle and the <tt>DBWSBuilder</tt> utility to use the DTP ModelBase bundle.<br><br>This option would solve all four issues identified above; however, there is an outstanding question - is the DTP ModelBase suitable for use at runtime? <br>I have asked the DTP PMC precisely this question.
| + | |
− | # Status quo - create/extend existing classes in <tt>o.e.p.tools.dbws</tt> to satisfy the requirements of the <tt>DBWSBuilder</tt> utility.<br><br> This option would solve none of the four issues identified above.
| + | |
With the decision to use a stripped-down version of JPub to get database metadata, bug 234681
changes from
'Improve DBWSBuilder utility's use of database metadata to support more auto-generated cases' to
'DBWSBuilder utility auto-generate XR artifacts for complex PL/SQL arguments'