ISSUE 122: The project method does not define behavior wrt ChangeSummary

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

Title: ISSUE 122: The project method does not define behavior wrt ChangeSummary

http://www.osoa.org/jira/browse/SDO-122

DESCRIPTION:
The project method does not define behavior wrt ChangeSummary. Moreover, change summary is not useable if the type system does not define (enough) containment relationships.

CATAGORIES
TOPIC 7: Type system and helpers
TOPIC 10: Containment

PROPOSAL:

The ChangeSummary information is shared between the different projections of a data object, that is, it is part of the underlying data, not part of the projection. In other words

O1.getChangeSummary()

contains the same list of modified data as

C2.getDataHelper().project(O1).getChangeSummary()

SDO 2.1 already has the restriction that a data object can be in the scope of at most one active change summary (i.e., on on which beginLogging has been called) at any time.

We should strengthen this restriction in SDO 3.0, if a data object is in scope for an active change summary, then none of its projection can be in the scope of another change summary.

The scope of a change summary is determined by the context in which beginLogging was called. That is, if O1.getChangeSummary().beginLogging() is called, then the containment structure of O1 (context C1) is used to determine the scope of the change summary.

Changes are tracked if they are within scope of the change summary, regardless of the context in in which the changes were made. This includes creates, deletes and modifies. All changes are visible for all projections.

To see why this solution is so desireable, consider the following scenarios

SCENARIO I: The type system used by the DAS represents most relationships as being non-containment (e.g., is java oriented). The DAS's client, on the other hand has much more containment, and the scope of changes that he wants to transmit to the DAS is reflected in this structure. In this case, we would want to first project the data object from the DAS's to the client's context, and then turn on logging. When the DAS processes the applyChanges request from the client, he can call getChangeSummary() to retrieve the client's changes.

SCENARIO II: The type system used by the DAS has a containment structure that he wishes to use as the definition of the change summary's scope. In this case, we imagine that the DAS knows which objects he's interested in persisting (and knows that it matches his containment structure). In this case, the containment structure of the client should be ignored. Under the proposal, the DAS would first call getChangeSummary().begingLogging() and then project to the client's context

(if necessary).

SCENARIO III: Both the DAS and it's client represent relationships as being non-containment, or we simply want to define a scope for the change summary that is independent of the containment structure of either party. What does one have to do with the other, anyway? In this case, we could define a 3rd context, with compatible types, but in which the containment matches the desired scoping for the change summary.