Re: [sdo] Adding convenience methods to Issue-66

["Blaise Doughan" <blaise.doughan@oracle.com>]

Title: Adding convenience methods to Issue-66

Hello All,

 

Personally I am more comfortable with the convenience methods than with the original project method.  My primary concern with the project method is that it leaves the DataObject being projected in an undefined state (and as you mention the corresponding bugs), the covenience methods could prevent this.

 

If the purpose of the project method is to allow data souce data with one set of containment relationships to be marshalled to XML with another set of containment relationships then the following would accomplish this:

 

    C2.getXMLHelper().save(O1);

 

If I wanted to move data from one context to another then we could do the following:

 

    C2.getCopyHelper().copy(O1);

 

I could even get behind:

 

    O2.set("x",O1);

 

If it was the same as:

 

    O2.set("x", C2.getCopyHelper().copy(01));

 

 

-Blaise

 

----- Original Message -----

From: Barack, Ron

To: sdo@lists.oasis-open.org

Sent: Tuesday, April 08, 2008 5:10 AM

Subject: [sdo] Adding convenience methods to Issue-66

Hi Everyone,

Assuming that Issue-66 is resolved today, I've been thinking about adding some convenience methods, to make this functionality more convenient.

The first thing I'd like to do is define what happens when an object from one context is passed to a helper in a different context.  Using our usual notation where O1 is an object in context C1, etc, the case that I think is most important is:

                C2.getXMLHelper().save(O1)

Should be logically equivelant to

            O2 = C2.getDataHelper().project(O1);
                C2.getXMLHelper().save(O2);
                O1 = C1.getDataHelper().project(O2);

In all the different flavors of save.  One advantage of using such functions would be that, at least as far as the user's concerned, O1 never enters an undefined state…I'm worried about bugs if the user forgets the second project.  The user would also not have to worry about the "cast back" being invalid.  Since O2 was never modified, the cast back must always work. 

Slightly more controversial might be:

               O2.set("x",O1);

I think this is equivalent to

               O2.set("x",C2.getDataHelper().project(O1));

Just giving some notice, since, if we do resolve 66 today, I'd like some clarity about the next steps in this direction.

Best Regards,
Ron