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/Dynamic/RefactorPhaseIForSparseMerge"
Line 48: | Line 48: | ||
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]] | 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]] | ||
− | === Phase II === | + | === Custom FetchGroups (Phase II) === |
+ | The next step in supporting DBWS sparse merge is to manually construct - using internal <code>DynamicEntity</code> APIs - working examples of | ||
+ | sparsely-built objects that contain custom FetchGroups. This new capability, while normally used for <b>read</b> operations, can also be used | ||
+ | for <b>write</b> operations. | ||
+ | |||
+ | === 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. |
Revision as of 10:42, 2 June 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
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.
DBWS UpdateOperation auto-generate Custom FetchGroups (Phase III)
The last step in supporting DBWS sparse merge is to changeo.e.p.internal.xr.QueryOperation
to auto-generate the necessary custom FetchGroups that were previously manually constructed in Phase II.