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/Dynamic/RefactorPhaseIForSparseMerge"

(New page: Tbd)
 
Line 1: Line 1:
−
Tbd
+
h2. Current status
 +
The current DBWS implementation (as of 10/02/18) does not handle SOAP update messages that contain changed-only information.
 +
For example, Employee 1111 is assigned a new job 'Dog walker':
 +
{code:xml|borderStyle=none|bgColor=#FFFFFF}
 +
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 +
  <env:Header/>
 +
  <env:Body>
 +
    <srvc:update_empType xmlns:srvc="urn:empService" xmlns:ns1="urn:emp">   
 +
      <srvc:theInstance>
 +
        <ns1:empType>
 +
          <ns1:empno>1111</ns1:empno>  <- primary key
 +
          <ns1:job>Dog walker</ns1:job> <- updated job title
 +
        </ns1:empType>   
 +
      </srvc:theInstance>
 +
    </srvc:update_empType>
 +
  </env:Body>
 +
</env:Envelope>
 +
{code}
 +
If this representation of Employee 1111 were to be marshalled into an object, most fields ({{ename}}, {{mgr}}, etc.) will contain {{null}}. Any attempt to merge this with a version retrived from the database would *over-write* committed data with nulls. Because of this, the complete _instance_ must be specified:
 +
{code:xml|borderStyle=none|bgColor=#FFFFFF}
 +
<srvc:theInstance>
 +
  <ns1:empType>
 +
    <ns1:empno>1111</ns1:empno>  <- primary key
 +
    <ns1:ename>NORMAN</ns1:ename>
 +
    <ns1:job>Dog walker</ns1:job>  <- only field that changed
 +
    <ns1:mgr>7698</ns1:mgr>
 +
    <ns1:hiredate>1998-09-08T00:00:00.0</ns1:hiredate>
 +
    <ns1:sal>10</ns1:sal>
 +
    <ns1:comm>0.1</ns1:comm>
 +
    <ns1:deptno xsi:nil="true"/>
 +
  </ns1:empType>   
 +
</srvc:theInstance>
 +
{code}
 +
Note the use of {{xsi:nil}} to indicate {{null}} for our Dog walker's department.
 +
 
 +
h2. {{isSet}} and {{DynamicEntity}}
 +
One solution to the above problem is to have a way to tell the difference between a field that has not yet been assigned any value vs. {{null}}.
 +
{code:java|borderStyle=none|bgColor=#FFFFFF}
 +
import org.eclipse.persistence.exceptions.DynamicException;
 +
 
 +
public interface IsSetable {
 +
 
 +
    public boolean isSet(String propertyName) throws DynamicException;
 +
}
 +
{code}
 +
It is helpful to note that the above interface is a subset of the {{DynamicEntity}} interface:
 +
{code:java|borderStyle=none|bgColor=#FFFFFF}
 +
//EclipseLink imports
 +
import org.eclipse.persistence.exceptions.DynamicException;
 +
 
 +
public interface DynamicEntity {
 +
 
 +
    public <T> T get(String propertyName) throws DynamicException;
 +
 
 +
    public DynamicEntity set(String propertyName, Object value) throws DynamicException;
 +
 
 +
    public boolean isSet(String propertyName) throws DynamicException;
 +
}
 +
{code}
 +
Thus, support for Sparse Merge will initially be done through {{DynamicEntity}}'s
 +
 
 +
h3. Changes to {{DynamicEntity}}
 +
The current EclipseLink {{DynamicEntity}} implementation (as of 10/02/18) sets default values for all fields, which defeats the ability of a merge algorithm to support 'sparse-ness'. Setting default values must be moved out of the 'core' Dynamic Persistence framework and relocated to a Dynamic 'helper' class such as DynamicTypeBuilder or JPADynamicTypeBuilder

Revision as of 14:29, 18 March 2010

h2. Current status The current DBWS implementation (as of 10/02/18) does not handle SOAP update messages that contain changed-only information. For example, Employee 1111 is assigned a new job 'Dog walker': {code:xml|borderStyle=none|bgColor=#FFFFFF} <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> 

 <env:Header/>
 <env:Body>
   <srvc:update_empType xmlns:srvc="urn:empService" xmlns:ns1="urn:emp">    
     <srvc:theInstance>
       <ns1:empType>
         <ns1:empno>1111</ns1:empno>   <- primary key
         <ns1:job>Dog walker</ns1:job> <- updated job title
       </ns1:empType>    
     </srvc:theInstance>
   </srvc:update_empType>
 </env:Body>

</env:Envelope> {code} If this representation of Employee 1111 were to be marshalled into an object, most fields (Template:Ename, Template:Mgr, etc.) will contain Template:Null. Any attempt to merge this with a version retrived from the database would *over-write* committed data with nulls. Because of this, the complete _instance_ must be specified: {code:xml|borderStyle=none|bgColor=#FFFFFF} <srvc:theInstance> 

 <ns1:empType>
   <ns1:empno>1111</ns1:empno>   <- primary key
   <ns1:ename>NORMAN</ns1:ename>
   <ns1:job>Dog walker</ns1:job>   <- only field that changed
   <ns1:mgr>7698</ns1:mgr>
   <ns1:hiredate>1998-09-08T00:00:00.0</ns1:hiredate>
   <ns1:sal>10</ns1:sal>
   <ns1:comm>0.1</ns1:comm>
   <ns1:deptno xsi:nil="true"/>
 </ns1:empType>

</srvc:theInstance> {code} Note the use of Template:Xsi:nil to indicate Template:Null for our Dog walker's department.

h2. Template:IsSet and Template:DynamicEntity One solution to the above problem is to have a way to tell the difference between a field that has not yet been assigned any value vs. Template:Null. {code:java|borderStyle=none|bgColor=#FFFFFF} import org.eclipse.persistence.exceptions.DynamicException;

public interface IsSetable { 

   public boolean isSet(String propertyName) throws DynamicException;

} {code} It is helpful to note that the above interface is a subset of the Template:DynamicEntity interface: {code:java|borderStyle=none|bgColor=#FFFFFF} //EclipseLink imports import org.eclipse.persistence.exceptions.DynamicException;

public interface DynamicEntity { 

   public <T> T get(String propertyName) throws DynamicException;

   public DynamicEntity set(String propertyName, Object value) throws DynamicException;

   public boolean isSet(String propertyName) throws DynamicException;

} {code} Thus, support for Sparse Merge will initially be done through Template:DynamicEntity's

h3. Changes to Template:DynamicEntity The current EclipseLink Template:DynamicEntity implementation (as of 10/02/18) sets default values for all fields, which defeats the ability of a merge algorithm to support 'sparse-ness'. Setting default values must be moved out of the 'core' Dynamic Persistence framework and relocated to a Dynamic 'helper' class such as DynamicTypeBuilder or JPADynamicTypeBuilder

Retrieved from "https://wiki.eclipse.org/index.php?title=EclipseLink/Development/Dynamic/RefactorPhaseIForSparseMerge&oldid=193151"

Back to the top