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/oNmMetadata"
< EclipseLink | Development | DBWS
(→General Solution) |
(→Issues Summary) |
||
| (10 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | == DBWS and new | + | == DBWS and new-format metadata == |
=== Issues Summary === | === Issues Summary === | ||
At some point in the future, DBWS will switch from using 'native' EclipseLink metadata (a.k.a. Project deployment xml) | At some point in the future, DBWS will switch from using 'native' EclipseLink metadata (a.k.a. Project deployment xml) | ||
| − | to using | + | to using oxm.xml and orm.xml (a.k.a JPA-style) metadata formats. In addition to using the new-format metadata, DBWS typically |
operates without persistent model classes; thus at runtime, a dynamic solution is required for the generation of | operates without persistent model classes; thus at runtime, a dynamic solution is required for the generation of | ||
persistent model classes. | persistent model classes. | ||
| Line 9: | Line 9: | ||
=== General Solution === | === General Solution === | ||
Similar to the current DBWS support, the new-format metadata files will be produced at design time by a DBWS utility. | Similar to the current DBWS support, the new-format metadata files will be produced at design time by a DBWS utility. | ||
| − | Later DBWS will | + | Later DBWS will at runtime read-in the new-format metadata files, dynamically generate persistent model classes, |
| − | and realize | + | and realize an environment that bridges between representation in a relational database and in an XML document. |
| − | and in an XML document. | + | |
=== Requirements === | === Requirements === | ||
| − | * the 'oNm.xml' metadata must support the majority of EclipseLink features ( | + | * the new-format 'oNm.xml' metadata must support the majority of EclipseLink features (see below) |
| − | + | * as there are no persistent model classes on the classpath, processing the new-format metadata must use only simple scalar objects (Strings, booleans, numbers, etc.) for all capabilities and settings. | |
| − | * as there are no persistent model classes on the classpath, processing the metadata must use only simple scalar objects (Strings, booleans, numbers, etc.) for all capabilities and settings. | + | * an in-memory model of the new-format metadata can be read in from an file (or stream, URL, etc.) without persistent model classes on the classpath. |
| − | * an in-memory model of the metadata can be read in from an | + | * an in-memory model of the new-format metadat can be serialized to a file (or stream, URL, etc.) without persistent model classes on the classpath. |
| − | * an in-memory model of the | + | * an in-memory model of the new-format metadata can be realized into runtime artifacts, including generating persistent model classes. |
| − | * an in-memory model of the | + | * generated persistent model classes must work when mapped simultaneously by both an OR and OX metadata model. <br/> i.e. an instance of a generated class must support the following: a row is retrieved from the database, built into an instance object and that very same object is serialized to XML - and vice-versa. |
| − | * generated persistent model classes must work when mapped simultaneously by both an | + | |
| − | * the | + | ==== OR new-format metadata requirements ==== |
| − | + | * Direct mappings with sufficient attribute information to support the range of datatypes used by JAX-WS web services | |
| + | * session-level settings: database platform information, container settings, etc. | ||
| + | * session-level queries whose arguments use complex types (advanced JDBC types; PL/SQL records+collections) | ||
| + | ** Struct and Array mappings ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=211299 211299], [https://bugs.eclipse.org/bugs/show_bug.cgi?id=221876 221876]) | ||
| + | |||
| + | ==== OXM new-format metadata requirements ==== | ||
| + | * Direct mappings with sufficient attribute information to support the range of schema types used in XML | ||
| + | * Composite, CompositeCollection and DirectCollection mappings | ||
| + | * Binary mappings to support inline or externally-attach'd binary data | ||
| + | |||
=== Open Issues === | === Open Issues === | ||
| + | * there are multiple solutions for dynamic generation of persistent model classes (SDO - <code>o.e.p.sdo.helper.DynamicClassWriter</code>; DBWS - <code>o.e.p.internal.dynamicpersist.BaseEntityClassLoader</code>). A separate functional spec should be created to examine the requirements and work required to refactor the multiple solutions into a common solution. | ||
=== Work Required === | === Work Required === | ||
| + | * metadata model classes to round-trip the new-format metadata | ||
| + | ** JPA - partial: works for read, does not (!) work for write | ||
| + | ** OX - nothing exists, design work just starting now but goal is to have it for EclipseLink 2.0 | ||
Latest revision as of 11:38, 4 June 2009
Contents
DBWS and new-format metadata
Issues Summary
At some point in the future, DBWS will switch from using 'native' EclipseLink metadata (a.k.a. Project deployment xml) to using oxm.xml and orm.xml (a.k.a JPA-style) metadata formats. In addition to using the new-format metadata, DBWS typically operates without persistent model classes; thus at runtime, a dynamic solution is required for the generation of persistent model classes.
General Solution
Similar to the current DBWS support, the new-format metadata files will be produced at design time by a DBWS utility. Later DBWS will at runtime read-in the new-format metadata files, dynamically generate persistent model classes, and realize an environment that bridges between representation in a relational database and in an XML document.
Requirements
- the new-format 'oNm.xml' metadata must support the majority of EclipseLink features (see below)
- as there are no persistent model classes on the classpath, processing the new-format metadata must use only simple scalar objects (Strings, booleans, numbers, etc.) for all capabilities and settings.
- an in-memory model of the new-format metadata can be read in from an file (or stream, URL, etc.) without persistent model classes on the classpath.
- an in-memory model of the new-format metadat can be serialized to a file (or stream, URL, etc.) without persistent model classes on the classpath.
- an in-memory model of the new-format metadata can be realized into runtime artifacts, including generating persistent model classes.
- generated persistent model classes must work when mapped simultaneously by both an OR and OX metadata model.
i.e. an instance of a generated class must support the following: a row is retrieved from the database, built into an instance object and that very same object is serialized to XML - and vice-versa.
OR new-format metadata requirements
- Direct mappings with sufficient attribute information to support the range of datatypes used by JAX-WS web services
- session-level settings: database platform information, container settings, etc.
- session-level queries whose arguments use complex types (advanced JDBC types; PL/SQL records+collections)
OXM new-format metadata requirements
- Direct mappings with sufficient attribute information to support the range of schema types used in XML
- Composite, CompositeCollection and DirectCollection mappings
- Binary mappings to support inline or externally-attach'd binary data
Open Issues
- there are multiple solutions for dynamic generation of persistent model classes (SDO -
o.e.p.sdo.helper.DynamicClassWriter; DBWS -o.e.p.internal.dynamicpersist.BaseEntityClassLoader). A separate functional spec should be created to examine the requirements and work required to refactor the multiple solutions into a common solution.
Work Required
- metadata model classes to round-trip the new-format metadata
- JPA - partial: works for read, does not (!) work for write
- OX - nothing exists, design work just starting now but goal is to have it for EclipseLink 2.0