You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Amita Vadhavkar <am...@gmail.com> on 2007/07/26 10:28:16 UTC
[SDO & RDB DAS] Problems in using new SDO APIs
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
Re: [SDO & RDB DAS] Problems in using new SDO APIs
Posted by 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
> >
>
Re: [SDO & RDB DAS] Problems in using new SDO APIs
Posted by kelvin goodson <ke...@gmail.com>.
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
>