You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by kelvin goodson <ke...@gmail.com> on 2007/01/08 12:29:01 UTC

[SDO Java] Semantics of Copy and Equality Test in the presence of a change summary

I was looking at what the spec says about copying and testing for equality
of data objects when they contain change summaries.

I put some notes at
http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDO/ThinkingAloud/ChangeSummaryOperations

The spec is reasonably clear in the case of copying, although I would
question whether we need more choice flexibility; i.e. a deep copy of a data
object with a change summary preserves all change history in the new data
object, which I wonder if all scenarios require?

The main issue is with respect to equality testing,  where there is some
ambiguity due to the use of the term "..... all their compared properties
are equal".  Had it said "..... all their properties are equal" then it
would be unambiguous, and it would be clear that for two data objects that
have change summaries to be equal, then the change summaries must also be
equal.  However, the "compared" qualifier is present and as far as I can
see, undefined in the context. Again, I can see scenarios when the test
should check the change summary and others when it shouldn't.  My guess is
that the most frequently desired behaviour is ignoring the change summary
differences.  Any thoughts?

Regards, Kelvin.

Re: [SDO Java] Semantics of Copy and Equality Test in the presence of a change summary

Posted by kelvin goodson <ke...@gmail.com>.
FYI  the definition of "compared" can be found in the javadoc of the
interface files

On 08/01/07, kelvin goodson <ke...@gmail.com> wrote:
>
> I was looking at what the spec says about copying and testing for equality
> of data objects when they contain change summaries.
>
> I put some notes at
> http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDO/ThinkingAloud/ChangeSummaryOperations
>
> The spec is reasonably clear in the case of copying, although I would
> question whether we need more choice flexibility; i.e . a deep copy of a
> data object with a change summary preserves all change history in the new
> data object, which I wonder if all scenarios require?
>
> The main issue is with respect to equality testing,  where there is some
> ambiguity due to the use of the term "..... all their compared properties
> are equal".  Had it said "..... all their properties are equal" then it
> would be unambiguous, and it would be clear that for two data objects that
> have change summaries to be equal, then the change summaries must also be
> equal.  However, the "compared" qualifier is present and as far as I can
> see, undefined in the context. Again, I can see scenarios when the test
> should check the change summary and others when it shouldn't.  My guess is
> that the most frequently desired behaviour is ignoring the change summary
> differences.  Any thoughts?
>
> Regards, Kelvin.
>

Re: [SDO Java] Semantics of Copy and Equality Test in the presence of a change summary

Posted by Yang ZHONG <le...@gmail.com>.
Maybe we/spec can consider multiple "equals" versions.

Similar to some people want String comparison case-sensitive while others
don't and JDK provides "equals" and "equalsIgnoreCase" respectively,
maybe we/spec can consider "equals" and "equalsIgnoreChanges"...


On 1/8/07, kelvin goodson <ke...@gmail.com> wrote:
>
> I was looking at what the spec says about copying and testing for equality
> of data objects when they contain change summaries.
>
> I put some notes at
>
> http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDO/ThinkingAloud/ChangeSummaryOperations
>
> The spec is reasonably clear in the case of copying, although I would
> question whether we need more choice flexibility; i.e. a deep copy of a
> data
> object with a change summary preserves all change history in the new data
> object, which I wonder if all scenarios require?
>
> The main issue is with respect to equality testing,  where there is some
> ambiguity due to the use of the term "..... all their compared properties
> are equal".  Had it said "..... all their properties are equal" then it
> would be unambiguous, and it would be clear that for two data objects that
> have change summaries to be equal, then the change summaries must also be
> equal.  However, the "compared" qualifier is present and as far as I can
> see, undefined in the context. Again, I can see scenarios when the test
> should check the change summary and others when it shouldn't.  My guess is
> that the most frequently desired behaviour is ignoring the change summary
> differences.  Any thoughts?
>
> Regards, Kelvin.
>
>


-- 

Yang ZHONG