|
|
| Line 12: |
Line 12: |
| | | Mike Norman | | | Mike Norman |
| | | 1.0 | | | 1.0 |
| | + | |- |
| | + | | 081120 |
| | + | | 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 'Improve DBWSBuilder utility's use of database metadata to support more auto-generated cases' to |
| − | [https://bugs.eclipse.org/bugs/show_bug.cgi?id=234681 bug 234681 ] <br/> | + | 'DBWSBuilder utility auto-generate XR artifacts for complex PL/SQL arguments' |
| − | 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 Refactoring ==
| + | |
| − | In EclipseLink, the Database Metadata 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 improved DataDictionary Queries requirements of the <tt>DBWSBuilder</tt> utility,<br>they violate the DRY (Don't Repeat Yourself) Principle: an existing Eclipse DTP ModelBase sub-project solves the identical problem.<br>Currently, the EclipseLink Database Metadata Model classes suffer from code duplication (for example three different classes describing Database tables), <br>and has little-to-no code reuse (i.e. no common class/interface to extend/implement).
| + | |
| − | | + | |
| − | === Options ===
| + | |
| − | # Refactor all EclipseLink Database Metadata Model classes to provide capabilities for both runtime and utilities and create a new optional bundle (similar to the existing <br>EclipseLink bundles for ASM and ANTLR). This would mean, for example, that EclipseLink runtime users that do not require DDL creation would not require <br>the additional bundle; similarly, EclipseLink runtime users that do not use <tt>o.e.p.platform.database.oracle.plsql.*</tt> would not require the new bundle. <br>For users of the <tt>DBWSBuilder</tt> utility, the new 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 <br>required on the classpath in addition to the <tt>eclipselink.jar</tt> and the other required <tt>.jar</tt>-files pertaining to Web services development (javax.wsdl, <br>javax.activation, javax.xml.soap jars) and the JDBC driver jar(s). <br><br>This option would eliminate internal code duplication and provide for code-reuse, but it does not address the DRY-issues raised by the DTP ModelBase.<br><br>
| + | |
| − | # Same as (1), but keep the Database Metadata Model classes in the EclipseLink core bundle. <br><br>Similar to (1), this option solves some issues but the EclipseLink core bundle would contain classes that no user requires at runtime.<br><br>
| + | |
| − | # Refactor the EclipseLink core bundle and the <tt>DBWSBuilder</tt> utility to use the DTP ModelBase bundle.<br><br>This option would solve all three 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.<br><br>
| + | |
| − | # 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 <b>none</b> of the three issues identified above.<br><br>
| + | |
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'
