Re: [DAS] Performance / API / Spec
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]
Re: [DAS] Performance / API / Spec
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]
Re: [DAS] Performance / API / Spec
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]
Re: [DAS] Performance / API / Spec
Hi Frank,
SNIP
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);
}
Oh - Great - I like that :-).
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?
Absolutely and thank you for the detailed explanation and OSOA link.
Cheers,
- Ole
SNIP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Performance / API / Spec
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]
[DAS] Performance / API / Spec
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]
