Hey Frank,
Frank Budinsky wrote:
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.
Great.
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).
Ah - I see.
DataGraph and DataObject do seem very closely related, like one is not
really needed.
I really like the EMF API here and wish the SDO API would do the same,
with a Resource (Which seems like a really good metaphor) containing a
graph of objects, and a ResourceSet containing many Resources. Then
start and stop logging could be called at the ResourceSet, Resource, and
DataObject levels, which seems like a clean way to cut it.
Anyways I'm jumping ahead :-)
I'll just collect ideas, and wait until the Charter gets finalized.
Thanks,
- Ole
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
