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 ------------------------------------------------------------------------------ == 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. + * 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 - Lots of useful state invariants are defined on P 78. + * 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. == 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. Is it necessary to go back to the xsd that was used orignally to generate ChangeSummaryImpl? I can't find that. - * 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. - * '''Further thoughts on above''' I think the above is misguided, since the ChangeSummary '' interface'' is already dual purpose -- no choices!! == Existing Patterns == === The "mixed" approach === - Assuming that consistency of approach is a good place to start from, 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. + 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. - '''However''' 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 coinstraints on that Property that make this approach workable, so the above is probably redundant if not completely wrong. + == Approach == + 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 ==== - * meta model - * do I need to tweak this to reflect the presence of ChangeSummary? - * is there a definitive update? + * 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? + * change getter behaviour on DataObject to look for CS on DO + * implementation will walk up the containment links towards the root, looking for a ChangeSummary attribute. + * cycle over attributes, checking for type = ChangeSummaryType (or instanceType = ChangeSummaryImpl?) + * could have BasicExtendedMetaData method similar to getContentKind + * 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? + * 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? + * 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 + * assumption: the meta model is the starting point for this development - F.B. -- No - * Is the Java rendering of the model created as part of the build? + * 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 @@ -46, +59 @@ * '''datagraph.xsd''' * the place where ChangeSummaryType type is defined * referred to in a comment in sdoModel.xsd (maintenance?) - * - * generator - * handle new annotation on xsds - * add new feature and getter - * run time - * permit dynamic type creation with change summary attribute - * update class to indicate change summary tracking possible - * create new attribute with - * 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? - * enumerate and guard new state invariants on runtime model - * - * - - - == arbitrary snippets for inclusion == - 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 + + 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. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
