WG: [sdo] ISSUE 122: The project method does not define behavior wrt Ch

Subject: WG: [sdo] ISSUE 122: The project method does not define behavior wrt ChangeSummary

We agreed to look at this issue during this week's teleconference, as in some opinions it blocks also SDO-125. The proposal in the JIRA suggests that the scope of the change summary (i.e., the set of nodes whose changes are tracked) be shared across all projections. I want to point out what we see as problems with the approach... perhaps we could discuss the alternatives during Tuesday's call.

Sharing the change summary's scope between projections can lead to unexpected behavior, since a modified entity can appear well outside the node where the change summary is located... during XML serialization, this could lead to GraphNotClosed exceptions.

One of the things that has changed since the last proposal on this issue was written, is that the DAS group has discussed the change summary a few times, and from these discussions it seems that most DAS's attach some semantic meaning to the containment structure of the change summary graph. It seems that most (all) DAS's interpret a delete of a contained node to imply a delete on the underlying data store, and an insert of a contained node to be a a create in the data store. Delete and inserts of non-containment properties are intepreted as adding or removing references (eg, foreign keys). If this is how DAS's are working, then a change summary cannot be interpreted seperately from the projection where the change summary is requested. We cannot lose the containment structure and consider only the set of nodes.

We have both these problems when we consider the use of keys. Let us consider a case where change tracking is enabled in a contexts with a large, complex domain model, and a change is made there, and then the model, together with the change summary, is projected into a context with only keys. If a user in the "smaller", pruned context attempts to read the change summary, then it is possible that the change summary's list of modified nodes contains entities that have been "pruned" from the context, whose types do not even exist there. I don't consider this use case very realistic, because I can't imaging why we are sending changes from a larger (server) model to a smaller (client) model for processing, but it is possible.

More troubling is that the semantic meaning associated with deleting a key is lost, and I consider this a more important and realistic use case. If we imagine that a key is deleted in the client projection, ie, a projection where a large domain model has been trimmed by replacing edge nodes with keys, then I believe this should be interpreted as deleting a reference, not deleting the entity. However, when we project to the context where the full domain model is, and in the process restore the keys to their entities, we lose the semantic that only a reference was deleted.

These consideration lead me to the conclusion that the change summary scope and structure should be maintained on a per-projection basis, not shared between projections. This behavior is also the most consistent with SDO 2.1. That is, according to this proposal, change summaries in 3.0 are also legal 2.1 change summaries, completely interoperable in terms of XML format, etc. The proposal in the JIRA would have created 3.0 change summaries that could not be interpreted by 2.1 implementations. We may wind up going there anyway, but at least this resolution will not require it.

What I think we need in any case is that the changes themselves survive the project operation. This is necessary if we assume that clients and servers may run in different contexts. This means clients can turn on change summary logging in a server context then project to a client context. The client can modifiy the graph, and then return the modified graph, which would then be projected back into the server context. The server context would then be able to use the change summary to detect the changes made by the client. In contrast to the proposal in the JIRA, the server context here could not be a JPA-like context that does not define containment relationships: such a context would not have a meaningful change summary. A server that did not have containment in its model would have to create a projection that has containment, presumably one that reflected a particular use-case of client. This is perhaps awkward, but seems to be the only way to capture the semantics associated with change summaries, as described above.

1. The scope of a change summary is defined by the containment structure of the projection where the ChangeSummary is located. That is, O1.getChangeSummary() returns the changes based on the containment properties defined in O1's context.

a) if changeSummary.beginLogging() is called in one context, and the object is projected to another context, where the data is modified before being projected back to the original context, then the change summary in the original context sees all the changes made by the "projected" context, as if the corresponding changes were made in his own context.

Von: Barack, Ron [mailto:ron.barack@sap.com]
Gesendet: Donnerstag, 10. April 2008 12:05
An: sdo@lists.oasis-open.org
Betreff: [sdo] ISSUE 122: The project method does not define behavior wrt ChangeSummary

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.

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

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.

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

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.

sdo message