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 Fri, 02 Jun 2006 13:37:57 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

------------------------------------------------------------------------------
  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: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message