[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [sdo] ChangeSummary presentation
Hi Guys,
I agree that orphan properties are expensive, and we should
not inflict these costs on users where they are necessary. If a
user uses a {SDO_URI}DataGraph as the envelope for the data object that he
wishes to transfer, then the implementation is probably going to have to
traverse the entire graph, looking for orphan properties. The
implementation really can't know before hand if the search for orphans will find
anything.
One way to handle this is to define {SDO_URI}DataGraph so
that the orphanHolder property comes after the technical root in the XML
stream. A clever implementation could then manage to traverse the graph
only once.
Another possibility is to chnage {SDO_URI}DataGraph
back to its 2.1 definition, ie, remove orphanHolders, and to create an new
DataObject Type, {SDO_URI}NonclosedDataGraph, that would be the same as our
current version of DataGraph. That way, the client has signified that he
is willing to pay the cost of having orphans.
Ron
Von: Blaise Doughan [mailto:blaise.doughan@oracle.com] Gesendet: Dienstag, 17. Februar 2009 15:20 An: Christophe Boutard Cc: sdo@lists.oasis-open.org Betreff: Re: [sdo] ChangeSummary presentation Some early comments: Slide 4 - The upcoming DAS... "DAS can be seen as the main consumer for ChangeSummary" I disagree with this statement. DAS owned DataGraph and at a time DataGraph was the sole owner of ChangeSummary, when DataObjects were given the ability to have ChangeSummary properites then SDO users developed their own uses for ChangeSummary (based on a diff for the graph). I think we're starting off on the wrong foot to break backwards compatibility here. Slide 8 - How does it work? (2/2) "At XML serialization time, orphan objects are added to orphan properties and then belong to the containment tree" How I read this is XML serialization now involves 2 passes. The first is to determine who the orphans are, the second to actually do the XML serialization. SDO 3.0 XML serialization will therefore be slower than SDO 2.1/2.1.1 XML serialization. Slide 18 - Objectives "Make events recorded in the ChangeSummary more easily usable by a DAS" Persistence solutions work quite well knowing the only the diff in a graph (current ChangeSummary definition). I believe the objective being proposed is make the events in the ChangeSummary directly usable by a DAS (i.e. a delete means remove the item from the database, as opposed to JPA that interprets the difference in the graph and based on the mapping metadata decides how to act). Slide 23 - How to track "Moves"? Isn't this what is currently done today in SDO 2.1/2.1.1? -Blaise Christophe Boutard wrote: 1348C4A8B6B9AF46A57B2CAA346E9C83DE7601@MAIL02.bedford.progress.com type="cite"> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]