ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "Tuscany/TuscanyJava/Design/SDO/ChangeSummary" by KelvinGoodson
Date Mon, 05 Jun 2006 09:14:30 GMT
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: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message