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 <[EMAIL PROTECTED]> 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
>
