Re: [SDO & RDB DAS] Problems in using new SDO APIs

[Amita Vadhavkar <am...@gmail.com>]

This issue is resolved. It was a problem internal to DAS and the patch
is ready to be reviewed for RDB DAS in JIRA-961

Regards,
Amita

On 7/27/07, kelvin goodson <ke...@gmail.com> wrote:
>
> Hi Amita,
>    The serialization of the opposite property reference in the graph looks
> like it is suffering from an issue that was reported in TUSCANY-1421 and
> is
> now fixed in the trunk/1.0 release.
>
> Regards, Kelvin.
>
> On 26/07/07, Amita Vadhavkar <am...@gmail.com> wrote:
> >
> > Hi,
> >
> > Current RDB DAS(deprecated SDO), by using, SDOUtil.createTypeHelper();
> is
> > creating
> > new TypeHelper instance for each SELECT query (GraphBuilderMetadata()).
> > But
> > this way
> > we end up in creating many TypeHelpers.
> >
> >
> -------------------------------------------------------------------------------------------------------------------------------------------
> > The new SDO API, gives another way where we can use the same TypeHelper
> > instance, through,
> >    HelperContext context = HelperProvider.getDefaultContext();
> >    TypeHelper th = context.getTypeHelper().
> >
> > With this the existing RDB DAS code needs a bit of caution, like -
> >
> > A> first check typeHelper.getType() , and only if it is null, then call
> > SDOUtil.createType(hc,...)
> > (because directly calling createType() on pre-existing Type, returns
> null)
> >
> > B> Also, create property in DataObject only when it is missing, like
> >   if(root.getProperty(tableName) != null &&
> >      root.getProperty(tableName).getType().getName().equals(
> > tableType.getName())){
> >      //dont do anything
> >   }
> >   else{
> >     property = SDOUtil.createProperty(root, tableName, tableType);
> >     SDOUtil.setMany(property, true);
> >     SDOUtil.setContainment(property, true);
> >   }
> >
> > But when tried with this approach, in cases of ApplyChange() {UPDATE},
> > what
> > is seen is SET clause
> > gets NULL values and WHERE clause gets correct values. WHERE clause is
> > derived from ChangeSummary
> > old values and is coming correct. In case of SET clause, what is seen
> is,
> > below line from RDB DAS
> > returns NULL-
> >    DataObject parent = dataObject.getDataObject(parentRef);
> >
> > Where serialized dataObject is -
> >
> > <?xml version="1.0" encoding="ASCII"?>
> > <dObj:dObj xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:dObj="dObj"
> >     xmlns:das="http:///org.apache.tuscany.das.rdb/das"
> > xsi:type="das:ORDERDETAILSDESC">
> >   <ID>3</ID>
> >   <ORDERID>1</ORDERID>
> >   <PRODUCTID>2</PRODUCTID>
> >   <DESCR>Descr 3,1,2</DESCR>
> >   <orderDetailsDesc_opposite>root.xml#//@ORDERDETAILS.0
> > </orderDetailsDesc_opposite>
> > </dObj:dObj>
> >
> > And parentRef is -
> >
> > orderDetailsDesc_opposite
> >
> > Question here is, when the serialized dump shows that there is
> > orderDetailsDesc_opposite
> > available, why dataObject.getDataObject() is not able to fetch it?
> >
> >
> -------------------------------------------------------------------------------------------------------------------------------------------
> > On the other hand, when the new SDO API, is used in the old way, i.e.
> keep
> > creating new
> > instances of TypeHelper (do not reuse the one from DefaultContext), the
> > above problem does
> > not occur. So, when done like below,
> >
> > HelperProvider helperProvider = HelperProvider.getInstance(); //this is
> a
> > new instance each time
> > HelperContext defHc = helperProvider.getDefaultContext();//and so are
> the
> > others
> > TypeHelper typeHelper = helperProvider.typeHelper();
> >
> > Surprisingly, here the DataObject serialization dump and parentRef value
> > are
> > exactly the same as above, and dataObject.getDataObject(parentRef) is
> able
> > to fetch NOT NULL DataObject.
> >
> > So, what is going on inside SDO/EMF? Why the same (at least from
> > serialized
> > string), DataObject's
> > getDataObject() method behaves differently in these two cases?
> >
> >
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
> >
> > Regards,
> > Amita
> >
>