Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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"

(Complex Sparse Merge (Phase IV))
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
<css>
 
<css>
   .source-java5 {padding:4px;border:1px solid black;}
+
  .source-sql {padding:1em;border:1px solid black; background-color: white;}
   .source-xml {padding:4px;border:1px solid black;}
+
   .source-java5 {padding:1em;border:1px solid black; background-color: white;}
 +
   .source-xml {padding:1em;border:1px solid black; background-color: white;}
 +
  .source-text {padding:1em;border:1px solid black; background-color: white;}
 
</css>
 
</css>
__NOTOC__
+
__NOTOC__  
 
== Sparse Merge ==
 
== Sparse Merge ==
  
Line 48: Line 50:
 
The current implementation needs to change the semantics of <code>isSet</code> to that of SDO - <code>isSet</code> returns <code>true</code> <b>only</b> when the public API <code>set(property, value)</code> is invoked. Please refer [[EclipseLink/Development/Dynamic#Refactoring_.28Phase_I.29 | to the page on Phase I Refactoring]] <br />
 
The current implementation needs to change the semantics of <code>isSet</code> to that of SDO - <code>isSet</code> returns <code>true</code> <b>only</b> when the public API <code>set(property, value)</code> is invoked. Please refer [[EclipseLink/Development/Dynamic#Refactoring_.28Phase_I.29 | to the page on Phase I Refactoring]] <br />
 
<br />
 
<br />
Est. number of days: 1.5 (a 'scratch' version of phase I already exists, it just needs merging)
+
 
 +
done
 +
<div id="Custom_FetchGroups">
  
 
=== Custom FetchGroups (Phase II) ===
 
=== Custom FetchGroups (Phase II) ===
Line 55: Line 59:
 
for <b>write</b> operations.
 
for <b>write</b> operations.
  
Est. number of days: 10 (functionality is new and need to get up to speed on it without interrupting Andrei's schedule)
+
done
  
 
=== DBWS UpdateOperation auto-generate Custom FetchGroups (Phase III) ===
 
=== DBWS UpdateOperation auto-generate Custom FetchGroups (Phase III) ===
 
The last step in supporting DBWS sparse merge is to change <code>o.e.p.internal.xr.QueryOperation</code> to auto-generate the necessary custom FetchGroups that were previously manually constructed in Phase II.
 
The last step in supporting DBWS sparse merge is to change <code>o.e.p.internal.xr.QueryOperation</code> to auto-generate the necessary custom FetchGroups that were previously manually constructed in Phase II.
  
Est. number of days: 10
+
done
  
 
=== Complex Sparse Merge (Phase IV) ===
 
=== Complex Sparse Merge (Phase IV) ===
 
The style of sparse merge that DBWS supports is actually rather simple - an object is built from a single sparse row/record; DBWS does not have to handle merging related objects or collections of related objects. These more complex sparse merge scenarios, while difficult to support (merging collections is related to calculating the [http://en.wikipedia.org/wiki/Levenstein_distance Levenshtein distance] which is O(MN) where M and N are the size of the collections), should be supported (at least for a subset of simple use-cases).
 
The style of sparse merge that DBWS supports is actually rather simple - an object is built from a single sparse row/record; DBWS does not have to handle merging related objects or collections of related objects. These more complex sparse merge scenarios, while difficult to support (merging collections is related to calculating the [http://en.wikipedia.org/wiki/Levenstein_distance Levenshtein distance] which is O(MN) where M and N are the size of the collections), should be supported (at least for a subset of simple use-cases).
 
  
 
Est. number of days: TBD
 
Est. number of days: TBD
 +
</div>

Latest revision as of 10:45, 7 October 2010


Sparse Merge

Current status

The current DBWS implementation (as of 10/02/18) does not handle SOAP update messages that contain changed-only information. The Update operation (part of CRUD lifecycle) requires 'theInstance' to be fully specified in the SOAPMessage; it would be useful to support an update where - excluding PK fields - only the changed elements are specified

For example, Employee 1111 is assigned a new job 'Dog walker':

<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>

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 retrieved from the database would *over-write* committed data with nulls. Because of this, the complete instance must be specified:

<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>

Note the use of xsi:nil to indicate null for our Dog walker's department.

DynamicEntity Refactor (Phase I)

The DynamicEntity interface allows one to tell the difference between 'the value was never set' and 'the value is currently null' using the boolean isSet(String propertyName) API on DynamicEntity. However, when an object is built, there are several policies that cause fields to be set (isSet returns true): Null policies, defaults for primitives, empty containers from Container policies, etc. This makes it impossible to handle sparse merges.

The current implementation needs to change the semantics of isSet to that of SDO - isSet returns true only when the public API set(property, value) is invoked. Please refer to the page on Phase I Refactoring

done

Custom FetchGroups (Phase II)

The next step in supporting DBWS sparse merge is to manually construct - using internal DynamicEntity APIs - working examples of sparsely-built objects that contain custom FetchGroups. This new capability, while normally used for read operations, can also be used for write operations.

done

DBWS UpdateOperation auto-generate Custom FetchGroups (Phase III)

The last step in supporting DBWS sparse merge is to change o.e.p.internal.xr.QueryOperation to auto-generate the necessary custom FetchGroups that were previously manually constructed in Phase II.

done

Complex Sparse Merge (Phase IV)

The style of sparse merge that DBWS supports is actually rather simple - an object is built from a single sparse row/record; DBWS does not have to handle merging related objects or collections of related objects. These more complex sparse merge scenarios, while difficult to support (merging collections is related to calculating the Levenshtein distance which is O(MN) where M and N are the size of the collections), should be supported (at least for a subset of simple use-cases).

Est. number of days: TBD

Back to the top