The SDO specification describes two means for obtaining a ChangeSummary :
i. Either from a DataGraph.getChagneSummary method
ii. As a property on a DataObject directly

Option i is nice and clean and there is only one ChangeSummary for each
object graph.  Option ii is not so nice but apparently very usefull, it
allows for multiple ChangeSummaries within a Graph as low as one is not
contained within the other.

For option ii when you are getting a change summary directly from the
DataObject this is represented as a property on the Type - I definately
don't like this as I think it confuses SDO with the model which should be
seperated.  However, that is what the specification says and the jist of my
questions was to determine how this was going to be represented in the DB.
For example it may be desirable to persist which DataObjects in a graph have
a change summary associated with them and their contained trees.  There are
xml solutions for this by adding them as a property but the original intent
of my questioning stemed from thinking that this would not work so well for
RDBs.

I don't know if I am off base here but this seems cumbersome to be mixing
SDO ChangeSummary with the model.

Robbie


On 8/18/06, Brent Daniel <[EMAIL PROTECTED]> wrote:

Robbie,

  The ChangeSummary should not be exposed as a Property, but rather
through the DataObject.getChangeSummary() method.

  I think what you're describing is not so much a DAS, but rather a
serialization to a database -- the difference being that a DAS uses
the SDO metadata (such as the ChangeSummary) to propagate changes to a
backend, whereas a serialization would attempt to maintain all of the
meta-information along with the DataGraph. In practice, a DAS would
not need to store ChangeSummary information in the database, because
the ChangeSummary would already have been used to update the database
copy.

Brent


On 8/17/06, Robbie Minshall <[EMAIL PROTECTED]> wrote:
> Looking at writing some test cases for the change summary on a
DataObject.
>
> If a DataObject can have a change summary then the Type must include a
> property of type ChangeSummary.  I am assuming that a DataObject graph
> heirachy can have multiple instances of this Type and there is a
violation
> only there are mulitple DataObjects with a non null property of type
> ChangeSummary.  Does that seem correct ?
>
> I am curious how this approach is going to be implemented for non XML
> persistence mechanisms/DAS implementaitons.  For the rdb DAS for example
> would one expect to add another column to the table schema?  Or is there
> perhaps going to be a set of tables in the DB for storing this type of
SDO
> specific information?  Perhaps since there seems to be very little
> protection anyhow ( another issue )  perhaps is there just going to be a
> default property of changeSummary on all DataObjects when created from
an
> RDB DAS ?
>
>
>
>
>
> --
> * * * Charlie * * *
> Check out some pics of little Charlie at
> http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/
>
> * * * Addresss * * *
> 1914 Overland Drive
> Chapel Hill
> NC 27517
>
> * * * Number * * *
> 919-225-1553
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
* * * Charlie * * *
Check out some pics of little Charlie at
http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/

* * * Addresss * * *
1914 Overland Drive
Chapel Hill
NC 27517

* * * Number * * *
919-225-1553

Reply via email to