Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by KelvinGoodson: http://wiki.apache.org/ws/Tuscany/TuscanyJava/Design/SDO/ChangeSummary ------------------------------------------------------------------------------ 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. + + Lots of useful state invariants are defined on P 78. == Queries == * 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. + * 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. It inherits from the EMF ChangeDescriptionImpl. The Tuscany class has methods associated with getting the DataGraph etc. These could return null if the instance isnt associated with a DataGraph, but this seems unclean. I think it would be best to generate an intermediate abstract class that supports the common aspedcts of the two scenarios (DataGraph and DataObject) and then derive from them. For this it would be good (necessary?) to go back to the xsd that was used orignally to generate ChangeSummaryImpl, but I can't find that. + * An issue with having two kinds of ChangeSummary might arise with SDOFactory and its getChangeSummary() method (which returns an EClass). Presumably the return type of this method is an EClass that has an instance class which is a concrete class bein the '''one''' class that we use to implement ChangeSummary, so if that's the case then that would have to be dealt with. == Existing Patterns == === The "mixed" approach === @@ -46, +54 @@ * change getter behaviour on DataObject to look for CS on DO * ? have BasicExtendedMetaData method similar to getContentKind which looks for annotation on EClass that changeSummary attribute present is true/false * cycle over attributes, checking for getFeatureKind(eAttribute) == ExtendedMetaData.CHANGESUMMARY_FEATURE - * '''hmmmm, I'm not sure I like this, it's not high perfomance, but it is consistent. What's the overhead? Should I have an instance member on the Type? Should I maintain both, and cache the Property value in the type when found? + * '''hmmmm, I'm not sure I like this''', it's not high perfomance, but it is consistent. What's the overhead? Should I have an instance member on the Type? Should I maintain both, and cache the Property value in the type when found? * enumerate and guard new state invariants on runtime model * * @@ -56, +64 @@ getChangeSummary() implementation will walk up the containment links towards the root, looking for a ChangeSummary attribute. + Page 41 of spec shows that the presence of a Property in a Type of the Type ChangeSummaryType is sufficient to trigger ChangeSummary behaviour. + A picture showing where we are ... attachment:ChangeSummaryImplSimpl.gif --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
