SDO Spec talks about BiDi support and BiDirectional in EMF is same as
Opposite in SDO terms.
SDOHelperImpl has implementation for setOpposite() and RDB-DAS relies on it
when defining Dynamic DO Properties - using
SDOUtil.setOpposite(parentProp, childProp);
SDOUtil.setOpposite(childProp, parentProp);
I took the dump of DAS formed DO using XSDHelperImpl.generate(List<types>).
As the above DAS code specifically sets the
opposites, the XSDHelperImpl dumps the xsd as below:- this can be used for
the TUSCANY-1483 to see the effect. I further
found that sdo-impl is failing to detect getOpposite() on it (:
DasOpposite.xsd
---------------------------
<xs:schema xmlns:sdo="commonj.sdo" xmlns:sdoJava="commonj.sdo/java"
xmlns:stn_1="http:///org.apache.tuscany.das.rdb/das";
xmlns:xs="http://www.w3.org/2001/XMLSchema";
attributeFormDefault="qualified" elementFormDefault="qualified"
targetNamespace="http:///org.apache.tuscany.das.rdb/das";>
<xs:complexType abstract="false" name="ORDERDETAILS">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0"
name="orderDetailsDesc" sdo:oppositeProperty="orderDetailsDesc_opposite"
sdo:propertyType="stn_1:ORDERDETAILSDESC" type="xs:anyURI"/>
</xs:sequence>
<xs:attribute name="ORDERID" type="xs:int"/>
<xs:attribute name="PRODUCTID" type="xs:int"/>
<xs:attribute default="0.0" name="PRICE" type="xs:double"/>
</xs:complexType>
<xs:complexType abstract="false" name="ORDERDETAILSDESC">
<xs:sequence>
<xs:element name="orderDetailsDesc_opposite"
sdo:oppositeProperty="orderDetailsDesc"
sdo:propertyType="stn_1:ORDERDETAILS" type="xs:anyURI"/>
</xs:sequence>
<xs:attribute name="ID" type="xs:int"/>
<xs:attribute name="ORDERID" type="xs:int"/>
<xs:attribute name="PRODUCTID" type="xs:int"/>
<xs:attribute name="DESCR" type="xs:string"/>
</xs:complexType>
</xs:schema>
-----------------------------------------------------------------------------------------
And had a small test like -
final HelperContext hc = SDOUtil.createHelperContext();
typeHelper = hc.getTypeHelper();
dataFactory = hc.getDataFactory();
xsdHelper = hc.getXSDHelper();
streamHelper = SDOUtil.createXMLStreamHelper(hc);
final URL url = getClass().getResource("/DasOpposite.xsd");
final InputStream inputStream = url.openStream();
xsdHelper.define(inputStream, url.toString());
inputStream.close();
DataObject dataObjectOrdDet = dataFactory.create("
http:///org.apache.tuscany.das.rdb/das";, "ORDERDETAILS");
DataObject dataObjectOrdDetDesc = dataFactory.create("
http:///org.apache.tuscany.das.rdb/das";, "ORDERDETAILSDESC");
System.out.println(dataObjectOrdDet.getInstanceProperty
("orderDetailsDesc").getOpposite());
But seems that this returns null. Anybody any clue why this returns null,
when the xsd shows use of sdo:oppositeProperty.
Also, will it be useful to add a set/getOpposite() test case to current SDO
test cases?
Regards,
Amita
On Dec 10, 2007 9:02 PM, David Adcox <[EMAIL PROTECTED]> wrote:
> Amita,
>
> If I understand what you are saying, I believe you have found one
> additional condition related to this issue that will precipitate the
> problem in T-1483. Right? If so, could you post a sample schema that
> would demonstrate the problem? I'll take a look at it.
>
> On Dec 10, 2007 8:32 AM, Amita Vadhavkar <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> > I just tried the patch from
> > https://issues.apache.org/jira/browse/TUSCANY-1483
> > and it works perfect. There may be just one more case of BiDirectional
> > feature where
> > SDOGenUtil.getQualifiedInternalPropertyID(genFeature) will get called.
> > For this the patch can be modified to include change in this file as
> well.
> > Suggestions?
> >
> > Regards,
> > Amita
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
