ISSUE 121: Adding convenience methods to Issue-66

["Barack, Ron" <ron.barack@sap.com>]

Title: Adding convenience methods to Issue-66

Hi,

 

Opening as an issue:

http://www.osoa.org/jira/browse/SDO-121

 

And might as well kick off discussion, too.

 

Blaise, why do you think DataObject.set() should do make a copy, rather than doing a simple project and project-back, like the other methods do?

 

After all, there is no pointer to the projected object returned.  O1 should stay active.  

 

Best Regards,

Ron

 

 

RAISED BY: Ron

CATAGORIES:
    Topic 6: SDO API
    Topic 7: Type System and Helpers
    Topic 10: Containment


DESCRIPTION:
The behavior of methods such as XMLHelper.save(DataObject) is unclear if the DataObject passed as argument is not in the same context as the helper itself.

From the usability standpoint, the project method may also be a bit low level for some use-cases. Therefore, the Helper methods that take data objects as parameters should be defined as performing implicit projects into the correct context.
For instance:

                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.

CopyHelper.copy should also be defined as performing a similar implicit project.

Another use case is:

               O2.set("x",O1);

Since we've stated that the set operation does not perform implicit casts, it should be acceptable to throw an exception here. On the other hand, an implementation could interpret this as

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

In no case should an object in one context be inserted as the value of a property in another context.

---

Von: Blaise Doughan [mailto:blaise.doughan@oracle.com]
Gesendet: Dienstag, 8. April 2008 15:58
An: sdo@lists.oasis-open.org
Betreff: [LIKELY JUNK]Re: [sdo] 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