RE: ISSUE 120: Simplified Projection

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

Hi Everyone,

I’ve modified this text based on Tuesday’s discussion.  I was thinking about what to say about using objects with helpers from different contexts, and I remembered that we discussed (and ruled out) the idea of “mixing” data between contexts way back in ISSUE 2 (http://www.osoa.org/jira/browse/SDO-2).  When I went back and looked at the text, I saw the compliance point (in section 4.6), which I really don’t like:

In order to assure consistent behaviour, an SDO implementation MUST ensure that every DataObject in a data graph, that is, in the transitive closure reachable from some root node, is associated with the same HelperContext. [COR04060001]

IMO, this is nonsense.  What does it mean that the implementation must “ensure” something.  How can we test that?  Do we want to require that an exception be thrown?  If so, we should say so, but we might want to at least allow an implementation to try a “project” here.  In addition to the last sentence here, which more or less says the same thing, I think we should either strike the above text from 4.6, or change it to the non-compliance relevant:

 

In order to assure consistent behaviour, every DataObject in a data graph, that is, in the transitive closure reachable from some root node, has to be associated with the same HelperContext.  Attempts to mix DataObjects from different HelperContexts in the same data graph result in implementation specific behavior.

Here’s the new text for the section on “project”.

3. The Project method

The HelperContext.project() method is used to copy data between contexts. This functionality is useful when transferring 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.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.  Although the object created by projection is initially consistent with the original object, either DataObject can thereafter be modified without affecting the other.   An SDO implementation MUST NOT allow modifications to an original object to be visible in a projection of the object, nor modifications to a projection to be visible in the original object. [COR04140305].

 

The project method is the only method in which objects from one HelperContext can be passed to objects or helpers associated with other HelperContexts.  Although it is possible for implementations to be more tolerant, for instance, by performing implicit projections in some cases, attempts to use objects or helpers from different HelperContexts together are illegal.   

 

 

Best regards,

Ron

 

From: Barack, Ron [mailto:ron.barack@sap.com]
Sent: Montag, 26. April 2010 14:50
To: sdo@lists.oasis-open.org
Subject: [sdo] ISSUE 120: Simplified Projection

 

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:

 

4. 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]

 

3. If P1.getType().isDataType() is true then O1.get(P1) is equal toO2.get(P2)
4. 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.