Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/DBWS/oNmMetadata"

(→‎'orm.xml' and 'oxm.xml' Metadata)
(→‎Issues Summary)
 
(23 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
== Use 'orm.xml' and 'oxm.xml' for Metadata ==
+
== DBWS and new-format metadata ==
−
At some point in the future, DBWS would like to switch from using 'native' EclipseLink meta-data
+
−
(a.k.a. project xml) to using JPA-style 'orm.xml' and JAXB3 'oxm.xml' meta-data (once Blaise gets
+
−
around to building JAXB3 for me!)
+
  
−
The DBWS requirements for a meta-data model are different from 'typical' usage - DBWS does not
+
=== Issues Summary ===
−
expose any domain model POJO classes; therefore, classes are dynamically generated at runtime when
+
At some point in the future, DBWS will switch from using 'native' EclipseLink metadata (a.k.a. Project deployment xml)
−
the service is initialized. Thus the DBWS utility builds meta-data model objects at design-time without
+
to using oxm.xml and orm.xml (a.k.a JPA-style) metadata formats. In addition to using the new-format metadata, DBWS typically
−
any domain model POJO classes on the classpath - the only types used in describing the meta-data are
+
operates without persistent model classes; thus at runtime, a dynamic solution is required for the generation of
−
Strings, booleans, enums and numbers.
+
persistent model classes.
  
−
High-level Requirements :
+
=== General Solution ===
−
* an in-memory instance of a meta-data model can be built solely from simple types without domain model POJO classes on the classpath
+
Similar to the current DBWS support, the new-format metadata files will be produced at design time by a DBWS utility.
−
* the model can be written to disk as an 'oNm.xml' file (where N can be: 'r '== JPA-style || 'x' == JAXB3)
+
Later DBWS will at runtime read-in the new-format metadata files, dynamically generate persistent model classes,
−
* an 'oNm.xml' file can be read in (from disk, stream, URL, etc) without domain model POJO classes on the classpath
+
and realize an environment that bridges between representation in a relational database and in an XML document.
−
* a meta-data model can be converted to 'real' runtime artifacts along with a custom classloader that dynamically generates domain model POJO classes
+
−
* a generated domain model POJO class must work when mapped via both an orm and oxm metadata model.
+
  
−
Thus a row can be retrieved from the database, built into an object and serialized to XML - and vice-versa.
+
=== 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. <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.  
  
−
Dynamic generation of domain model POJO classes
+
==== OR new-format metadata requirements ====
−
Currently, a 'least-effort' code-gen strategy is used - all generated classes are a sub-class of a 'helper' class
+
* Direct mappings with sufficient attribute information to support the range of datatypes used by JAX-WS web services
−
<code>o.e.p.internal.dynamicpersist.BaseEntity</code>:
+
* session-level settings: database platform information, container settings, etc.
−
<source lang="java5">
+
* session-level queries whose arguments use complex types (advanced JDBC types; PL/SQL records+collections)
−
public class BaseEntity implements PersistenceEntity, Cloneable {
+
** 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])
  
−
    protected Object[] fields; // BaseEntities only deal with Objects, never
+
==== OXM new-format metadata requirements ====
−
                                // primitives
+
* 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
  
−
    protected BaseEntity() {
+
=== 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.
  
−
    public Object get(int i) {
+
=== Work Required ===
−
        return fields[i];
+
* metadata model classes to round-trip the new-format metadata
−
    }
+
** JPA - partial: works for read, does not (!) work for write
−
    public void set(int i, Object aFieldValue) {
+
** OX - nothing exists, design work just starting now but goal is to have it for EclipseLink 2.0
−
        fields[i] = aFieldValue;
+
−
    }
+
−
...
+
−
</source>
+
−
Member fields are uniquely identified by their index into the fields Object array - this works with the EclipseLink native
+
−
meta-model via the use of custom o.e.p.mappings.AttributeAccessor's that translate requests for an object's
+
−
attribute into the correct fields index (SDO uses a similar strategy, but different impl). The custom accessors are added
+
−
to the Project after it is built from the meta-data and custom classloader, but before it is logged in .
+
−
 
+
−
It is unclear if use of the public JPA runtime artifacts (javax.persistence.EntityManagerFactory,
+
−
javax.persistence.EntityManager) prevents the above 'trick' (their lifecycle may not be able to distinguish the
+
−
after-build-but-before-login point in time, or access to the granularity of individual mapping's accessors may not be available).
+
−
An alternate code-gen strategy - with actual member fields - may be required.
+

Latest revision as of 11:38, 4 June 2009

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
Retrieved from "https://wiki.eclipse.org/index.php?title=EclipseLink/Development/DBWS/oNmMetadata&oldid=156828"

This page was last modified 11:38, 4 June 2009 by Eclipsepedia anonymous user Unnamed Poltroon.

Back to the top