OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[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.

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

Hi Christophe,

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?


Christophe Boutard wrote:
1348C4A8B6B9AF46A57B2CAA346E9C83DE7601@MAIL02.bedford.progress.com type="cite">

Hi all,

Please find the presentation for the ChangeSummary discussion.



Christophe Boutard
Development Manager, Data Services
Phone: +33 (0)1 46 14 13 06 | Fax: +33 (0)1 46 14 13 01
Email: christophe.boutard@datadirect.com

DataDirect Technologies    
21 rue des Trois Fontanots
| 92000 | Nanterre | France


--------------------------------------------------------------------- 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]