Thanks Frank, that makes things much clearer. Does anyone have any idea why there is no standard mechanism to declare a property of a certain type as being the "identifier" property? If your type is created from an XSD, you can declare certain attributes to be ID's. Then the SDO implementation needs to keep track of this because sdo-refs should use that property instead of an SDO xpath expression. But I don't understand why this is not visiable in the SDO metamodel.
Bert Frank Budinsky <[EMAIL PROTECTED]> 16/06/2006 21:04 Please respond to [email protected] To [email protected] cc Subject Re: [spec] trying to understand ChangeSummary Hi Bert, > I'm trying to get a conceptual understanding of what a ChangeSummary is > and what you can do with it. I hope this is a good place to discuss this. Since there's no public forum for discussing the SDO spec (although there probably should be) and since Tuscany is an open source implementation of SDO, I guess we're your only public choice :-) > 1. A DataGraph is a structured graph of DataObjects right. > 2. A ChangeSummary gives me a list of all DataObjects from my DataGraph > that have changed (including created & deleted) right. > 3. For each DataObject that has changed, I can see what properties have > changed and can access the old and new value right. > 4. In case non-datatype properties have changed, the old value is the > reference the object had before change tracking started. The contents of > the DataObject that is referred to can have changed. > For instance suppose I have the graph containing three data objects (for > simplicity all of the same type): > > A(name=a) -> B(name=b) -> C(name = c) > > where arrows indicate non-datatype properties and name is a string > property. If this graph is changed into > > A(name=a) -> C(name=cc) -> B(name = bb) > > Then all three objects will have changed. For object A, one property has > changed: the reference (B -> C). If I ask the changesummary for the old > value of the reference I get a reference to B whose name is equal to bb. > This might seem a bit strange because in the old days, A referred to B > with name=b. you're right, but the basic idea is that it gives you the object it used to point to. If that object itself has changed you need to look at the ChangeSummary's old values for its properties as well. > 5. Suppose I now want to make an update service that uses the > ChangeSummary to update my back-end datastore. > > Then, the only way I can think of that makes ChangeSummary useful is > either when > 1. I have implementation specific identifier properties are > associated with each type [for instance by giving each of my DataObject > types a URI property] > or > 2. The structure of my DataGraph (i.e. the links between the > various DataObjects) can't change I'm not an expert on how people implement DAS's, but I think approach #1 is the common way to correlate. Maybe someone with more DAS knowledge can comment. I hope this helps. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
