Differences between revisions 12 and 13
Revision 12 as of 2006-06-05 14:46:34
Size: 6525
Revision 13 as of 2009-09-20 22:48:42
Size: 6529
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 68: Line 68:
attachment:ChangeSummaryImplSimpl.gif {{attachment:ChangeSummaryImplSimpl.gif}}

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)

  • A Type for a DataObject has a Property for containing a ChangeSummary. (I.e. would expect to see the Property in the Type.getProperties() call.)

  • The type of the Property is commonj.sdo.ChangeSummaryType

  • There are lots of useful state invariants are defined on P 78.
  • The ChangeSummary interface defines methods that reflect the association with both DataGraph and DataObject, so the test for the presence of the DataGraph wrapper is if getDataGraph() returns null.


  • I don't suppose this is the case, but just to clarify, if a Type is open and a ChangeSummary instance is attached to an instance my assumption is that this would not trigger change recording activity.

  • how do you trigger DocumentRoot to be a class that supports change tracking? A global element of the type ChangeSummaryType? -- A little quirky!

  • The spec says that a ChangeSummaryType must be isMany=false and readOnly=true, but the example on P 78 doesnt show that explicitly. Does that mean that these are the normal defaults (can't be!), or that we apply special defaults, or that the example is wrong.

    • Answer, p. 94 shows special defaulting behaviour of XSD to SDO mapping, readOnly=true.
  • The existing Tuscany source file for ChangeSummaryImpl is generated, but I can't find an xsd for it. Is it necessary to go back to the xsd that was used orignally to generate ChangeSummaryImpl? I can't find that.

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

  • model definition
    • how do you trigger DocumentRoot to be a class that supports change tracking? A global element of the type?

  • run time
    • permit dynamic type creation with change summary attribute
      • update class to indicate change summary tracking possible
      • create new attribute with
    • the default value for a ChangeSummary is not null. It is a ChangeSummaryImpl with logging set to on/off -- check which it is?

      • when does the ChangeSummary get instantiated (if default is loggin is on , then it makes sense to do it in the factory)

    • change getter behaviour on DataObject to look for CS on DO

    • enumerate and guard new state invariants on runtime model
      • e.g. no overlap (how do I guard that? -- something in existing presence of Notification?)
  • generator
    • is there anything out of the ordinary that the generator must do?
    • could have get<ChangeSummary>() implement the defaulting behaviour at the top level?

  • meta model (saving this stuff about metamodel here - although I think it is irrelevant and misguided, but I may change my mind)
    • Is there a change required in the metamodel to support this?
    • can the behaviour change be implemented without a change to the meta model? (Yes, I think so)
    • what is the definitive source of the meta model? SDO.mdl file? ecore? xsd?
    • assumption: the meta model is the starting point for this development - F.B. -- No
    • Is the Java rendering of the metamodel created as part of the build?
    • do I have the freedom to change the xsds and xml files in the sdo-api project, or are these fixed by the spec?
    • sdoModel.xsd (meta meta model?)

      • either
        • add attribute "changeSummary" (is that a good name? Ought to be an adjective) as a boolean to "Type"
        • or perhaps it gets added via the anyAttribute and we update the sdoXML.xsd?
    • sdoModel.xml facilitates a run time representation of the sdo model as object instances (but is that what it's for?)

    • sdoJava.xsd

      • perhaps the changeSummary attribute (or whatever its called) gets added as a global attribute in here, and may be aded to the model by virtue of the xsd:anyAttribute on sdoModel.xsd (my feeling is that this should be a proper attribute on the model)
    • datagraph.xsd

      • the place where ChangeSummaryType type is defined

      • referred to in a comment in sdoModel.xsd (maintenance?)

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)