ChangeSummary Design Jottings

A place to hold thoughts about how to make ChangeSummary work as DataObject properties rather than being constrained to properties of DataGraphs.

Spec Constraints

(refs to the spec are to the 2.01 version, Nov 2005)


Existing Patterns

The "mixed" approach

If consistency of approach is a good place to start from, then it would be sensible to follow the pattern of the inclusion of the mixed feature as a property of a class which occurs when mixed = true. Finding this feature is based on annotation of the feature with a FEATURE_KIND, i.e. for the mixed feature this is ExtendedMetaData.ELEMENT_WILDCARD_FEATURE. But the spec says that the trigger for ChangeSummary on a DO is the presence of a Property of type commonj.sdo.ChangeSummaryType in the type, and there are lots of sensible constraints on that Property that make this approach workable, so following the annotation approach is probabably unnecessary and wrong.


So my current feeling is that I will manually edit the existing ChangeSummaryImpl to establish the potential association. I'll probably add an instance member to the Type to cache the property, once found, (and maybe use a singleton instance to record that the type doesn't have such a property?)

Issues/Things I can see that would need to be done

A picture showing where we are ...


It wouldn't be appropriate from a memory footprint perspective to symmetrically inflate the DataObject with an instance member in the way that DataGraph has one. So the Type will cache the ChangeSummary property.

Implementation Work

new basic test schema

   <xsd:element name="class" type="chg:simpleTrackedType"/>

   <xsd:complexType name="simpleTrackedType" >
       <xsd:element name="value" type="xsd:string" />
       <xsd:element name="changeSummary" type="sdo:ChangeSummaryType" /> 


Tuscany/TuscanyJava/Design/SDO/ChangeSummary (last edited 2009-09-20 22:48:42 by localhost)