ISSUE 120: Simplified Projection

["Barack, Ron" <ron.barack@sap.com>]

Hi Everyone,

 

I took an action item to rewrite the chapter on projection without requiring “object identity” and without an “undefined state”.  Here is a first draft:

 

3. The Project method

The DataHelper.project() method is used to move data between contexts. This functionality is useful when moving data between loosely coupled applications, or when imposing alternate structures on existing models, for instance when imposing an XML containment hierarchy on data coming from a relational database.  This section describes the behavior of the project method in terms of an  object O1 with type T1 in HelperContext C1 and a second context C2 that defines a Type T2, that is compatible with T1 according to the definition in section 4.5.4 The method

     DataObject O2 = C2.getDataHelper().project(O1);

 

MUST return a DataObject O2 such that O2.getType() is T2 [COR04140301].  The definition of Type Compatibility given in section 4.5.4 means that for every property P1 that can be accessed on O1 there is a corresponding property P2 accessible from O2.  The types of the two corresponding properties are either directly compatible (i.e., P1.getType() is compatible with P2.getType()) or one side is compatible with the keyType of the other side (i.e., either P1.getType().getKeyType() is compatible with P2.getType() or P1.getType() is compatible with P2.getType().getKeyType()).  The behavior of the project method when moving from complex objects into keys or back again is dealt with is section 4.14.4.  For each property P2 in O2 that is directly related to a property P1 in O1, the project method MUST initialize the values of the property such that: [COR04140303]

 

1. If P1.getType().isDataType() is true then O1.get(P1) is equal toO2.get(P2)
2. If P1.getType().isDataType() is false then C2.getEqualityHelper().equals(O2.get(P2), C2.project(O1.get(P1))

If O1 and O2 are both sequenced, then the order of the elements in the sequences MUST match. [COR04140302]

It is possible that a valid data graph cannot be projected into another context, because it violates the restrictions implied by the target context’s metamodel.  Such restrictions include those implied by the type’s containment structure, e.g., there can be no objects in the projected containment graph that have more than one container.  For instance, consider an object O1, with Type T1, in context C1.  Assume that it has 2 properties, “a” and “b”, neither of which are marked as being a containment property.  Then it could be legal to set the value of these properties to the same object, N1.   Now consider a second type, T2, in context C2, that is compatible with T1 but in which the properties “a” and “b” are both marked as being containment properties.  Then the DataObject O1 cannot be projected into the context C2, because the object N1 would project to an object that has conflicting containment properties.  Attempting to perform such a projection is a user error and results in undefined behavior.