Hi Ole,

I found out today that it will take 2-3 months before the OASIS SDO 
charter will be finalized and the discussions can begin. I'm involved with 
the charter, so I can tell you that both of the issues you mentioned are 
in scope for SDO 3, so they will be discussed once things get started.

For DataGraph.setRootObject(), the proposal is to either deprecate the 
DataGraph interface entirely or to make DataGraph also be a DataObject. 
Either way, you would set the root object using DataObject.set(). The root 
object would be an open content property so you could set it by simply 
calling something like this: dataGraph.set("company", myCompany).

Frank.

Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/18/2007 01:41:53 PM:

> Hi Frank,
> 
> I looked around osoa.org to sign up for a account,
> but could not find a signup
> page.  Do you know if it's up yet?
> 
> Also, I noticed that there is no
> setRootDataObject() method on the
> DataGraph interface, but there is one on the
> implementation.
> 
> It seems like it should be in the interface as well.
> 
> Do you know whether there is a "Whiteboard" somewhere,
> where we can post SDO API suggestions?  Should I perhaps
> JIRA these in the Java Spec API section?
> 
> Thanks,
> - Ole
> 
> 
> 
> Frank Budinsky wrote:
> > Hi Ole,
> > 
> > I'm not sure what reasoning was to justify the ChangeSummary API which 

> > requires you to iterate over the one list returned by 
> > getChangedDataObjects() and then call isCreated(), isModified(), or 
> > isDeleted() to see if it was a C, U, or D.
> > 
> > If you look at class ChangeSummaryImpl, you'll notice that in Tuscany 
we 
> > actually implement this with three separate lists under the covers. 
The 
> > isDeleted() method, for example, looks like this:
> > 
> >   public boolean isDeleted(DataObject dataObject)
> >   {
> >     return getCachedDeletedObjects().contains(dataObject);
> >   }
> > 
> > I know that there is a proposed SDO 3 work item to revisit 
ChangeSummary 
> > to see if the API could be improved. Perhaps you'd like to get 
involved in 
> > the spec discussion on this issue, when it begins? Now that it's 
moving to 
> > OASIS (http://osoa.org/display/Main/News+about+SCA+and+SDO), SDO 
design 
> > discussions will be open to everyone.
> > 
> > Frank.
> > 
> > 
> > Ole Ersoy <[EMAIL PROTECTED]> wrote on 04/17/2007 12:27:58 PM:
> > 
> >> Hi Guys,
> >>
> >> I have a few performance related
> >> questions with respect to change
> >> summary processing (Really spec related - hope it's ok that I float 
it 
> >> here).
> >>
> >> I just looked at the Change
> >> summary API and it looks like
> >> the DataGraph sets the
> >> isDeleted and isCreated
> >> flags on each DataObject instance
> >> that it creates or deletes, and
> >> then it adds them to the change summary.
> >>
> >> It seems like change summary
> >> processing would perform better
> >> if the Change summary had CUD lists.
> >>
> >> So one list for:
> >> - Created DataObjects
> >> - Deleted DataObjects
> >> - Update DataObjects
> >>
> >> Then these lists could be processed directly by the
> >> DAS and it would not have to check what type CUD
> >> was done for each object.
> >>
> >> Then the DataGraph only adds objects to these lists
> >> and does not need to set any flags, which means that
> >> during processing the flags don't need to be checked
> >> in order to perform the right type of processing.
> >>
> >> I'm still getting my feet wet here, but I thought I'd throw this out 
> >> there, since to me it seems like it's simpler and more light weight.
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >> - Ole
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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]
> 


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

Reply via email to