[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] change summary.doc: Modifications
Hi Everyone,
Two changes were suggested to the ChangeSummary/
OrphanHolder write up. The first was that the references to DataGraph be
removed. I've created another issue to deal with a general clean up of the
spec (SDO-161), so that the modificiation to this proposal deals only with the
new text. The main references to DataGraph are in 4.3.2 and 4.3.8. I
think it actually makes sense to combine these sections, as
follows:
4.3.2 ChangeSummary
Root
ChangeSummaries become associated with
DataObjects when the DataObject includes a Property with type
ChangeSummaryType. The
ChangeSummary root is the DataObject having the ChangeSummary property. ChangeSummary.getRootObject() MUST
return the ChangeSummary root.
Calling DataObject.getChangeSummary() on the ChangeSummary root, or on any DataObject
contained, directly or indirectly, by the ChangeSummary root, MUST return the same ChangeSummary object.
It MUST also be possible to retrieve this object
using DataObject.get(“changeSummaryProperty”) where “changeSummaryProperty” is
the name of a property whose Type is ChangeSummaryType. The following rules and restrictions
apply to ChangeSummary properties: –
Types are allowed to contain at most one
property with type ChangeSummaryType. –
A property with type ChangeSummaryType must
have many=false and readOnly=true. –
The scope of ChangeSummaries may never
overlap. If a DataObject has a property of type ChangeSummary, it cannot be
directly or indirectly contained or otherwised referenced by any other
DataObjects that have a property of type ChangeSummay.
–
When the DataObject containing the
ChangeSummary is created, logging is by default off. Before any changes will be
logged, ChangeSummary.beginLogging() must be
called. – The ChangeSummary will not contain the creation or deletion of its containing DataObject. we could then remove section 4.3.8
The other change we talked about was to remove the
restriction that the orphanHolder properties be on the ChangeSummary root.
I'm having second thoughts about this, because it means that we need
to traverse the scope looking for orphanHolders before we traverse it
(again) looking for changed objects. I wonder if this is really worth
it. But just so that we have something concrete to
discuss, here is the modification to section
4.3.3
The
scope of a ChangeSummary is defined as the set of DataObjects reachable from the
ChangeSummary root either through containment or over any orphanHolder
properties. All
orphanHolders associated with the ChangeSummary root or any DataObjects contained, directly or indirectly
by the ChangeSummary root MUST be considered in determining the scope.
In other words the scope of the change summary is the same set of
DataObjects that would be in the sub-tree whose root node is ChangeSummary root,
if the graph were serialized to XML. Notice that only orphanHolders reachable through
containment are considered, orhanHolders on orphans being pretty much a corner
case as far as I can see, and really not justifying the additional
costs.
Best
Regards,
Ron
Von: Frank Budinsky [mailto:frankb@ca.ibm.com] Gesendet: Montag, 22. Juni 2009 19:40 An: sdo@lists.oasis-open.org Betreff: Re: AW: [sdo] change summary.doc Hi Blaise,
Hi Ron, "I agree that it might seem odd that an object that is moved outside the scope of the change summary is rendered as a delete, but I don't think it's any odder for the proppsed definition of scope (ie, including orphanHolders) than for the 2.1 definition of scope. In other words, if C was previously contained by B, and then moved to A, then it would also be rendered in the CS as a delete. Does the behavior seem more incorrect for orphanHolders than it does for containment? In both cases, we have the same simple rule: anything that was in scope before, but is no longer is scope is rendered as a delete." The reason it seems "more incorrect" is that in the containment case (see below) if B had a ChangeSummary and a containment relationship was formed between A & C then B would lose its reference to C. A --containment--> B --containment--> C In the example I gave before (see below), B will still reference C (as strongly as it did before), but the ChangeSummary will tell me something changed (when nothing really did). A --containment--> B --non-containment--> C -Blaise Barack, Ron wrote:
I think your understanding of the proposal is correct. I agree that it might seem odd that an object that is moved outside the scope of the change summary is rendered as a delete, but I don't think it's any odder for the proppsed definition of scope (ie, including orphanHolders) than for the 2.1 definition of scope. In other words, if C was previously contained by B, and then moved to A, then it would also be rendered in the CS as a delete. Does the behavior seem more incorrect for orphanHolders than it does for containment? In both cases, we have the same simple rule: anything that was in scope before, but is no longer is scope is rendered as a delete. The trouble with restricting orphanHolders to root elements is that, effectively, it makes that scope of the change summary the entire graph, and I think, since CS has performance and memory costs, it would be better to be able to express the boundries, ie, that scope is not the entire graph. I believe DataDirect has mentioned in the past the idea of using DataObject.delete() to determine which orphans should be rendered as being deleted, and which should be rendered as simply no longer being referenced. A similar API could be used for distinguishing orphans that should be rendered as created. The idea has some appeal, since removing a non-containment reference maybe should have different semantics that removing a containment reference (indeed, this is the case with 2.1). I'll leave it to them to provide details. I guess we have something (besides headers) to discuss at tomorrows meeting ;-). Ron Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Montag, 22. Juni 2009 15:32 An: Barack, Ron Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] change summary.doc Hi Ron, Still working though your ChangeSummary document. I have a question about the following use case: A --containment--> B --non-containment--> C From your document: If B has both a ChangeSummary and orphan property then C is in the scope of B's ChangeSummary. Question: If a containment relationship forms between A & C then what is the impact on the ChangeSummary? Since C is no longer an orphan (A is its parent) and C is not reachable through B's containment tree it is no longer in the ChangeSummary's scope, but it seems incorrect to treat C as being removed. Impact: Are orphan properties restricted to root objects? At least when ChangeSummary is involved? -Blaise Barack, Ron wrote:
As promised, here is some wording towards the resolution of issue 160. I'm using the document Bryan sent out as a resolution for 139 as the basis. Section 4.3 is heavilly modified, and partially combined with section 6.4. Also chapter 11 has been extended. Please review. Best Regards,
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]