This is a discussion currently going on among the spec collaboration group. It looks like the SDO 2.1 spec will probably introduce something like what you're suggesting.
Frank. [EMAIL PROTECTED] wrote on 06/19/2006 03:49:44 AM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
