Hi Scott,
Brent just checked in RDB DAS changes to make use of the the new SDO
utility created for TUSCANY-670.
Can you try your app again with these latest changes and let us know how
it goes?
Thanks!
--Kevin
Scott Kurinskas wrote:
Hi All,
I thought I'd check-in regarding the status of this request? Kevin was kind
enough to log jira issue (http://issues.apache.org/jira/browse/TUSCANY-670),
but I'm blocked. Any chance there is a workaround available? I'd like to
use the DAS for DB access, but would be willing to map to/from a XSD if that
would eliminate the current problem.
Thanks,
Scott
-----Original Message-----
From: Kevin Williams [mailto:[EMAIL PROTECTED]
Sent: Friday, August 25, 2006 3:25 PM
To: [email protected]; [email protected]
Subject: Re: DataObject/DataGraph Serialization & DataGraphRoot
Hi Yang,
Comments in line ...
Yang ZHONG wrote:
You may need to serialize the generated SDO metadata. On the other
hand, I recommend the scenario design to be reconsidered.
Thank Frank for suggesting a SDOUtil helper taking a list of Types for
DAS to serialize all generated Types along with DataGraph.
If you're willing to do that, I'll implement and send it out.
Yes. Please implement this method. If I understand correctly, the function
exists today in EMF but we prefer to stay with SDO apis. Also, I am not
sure why the method should take a list of generated Types since they exist
in the graph already. So, why not a method something like
this: serializeTypes() ?
At the same time, I have some thoughts on the scenario design.
DataBase schema is unlikely changed frequently, it's inefficient for
DAS to always generate same SDO metadata over and over again on every
single query, it's also inefficient to serialize same SDO metadata
over and over again on every single invocation back to client. A
typical customer scenario is, both client and server have SDO metadata
already, therefore SDO metadata serialization isn't really necessary,
and SDO metadata generation from DAS isn't really necessary. I know an
early version of DAS (it was under different name) can accept existing
SDO metadata and generate only SDO instances. My previous product
customers actually complained about the very poor performance caused
by repeating same SDO metadata generation and serialization.
So, are you interested in trying such scenario so that you won't have
"type not found" problem?
Solution 2-1 (typical real scenario):
1. deploy SDO metadata to both client and server 2. instruct DAS to
accept the existing SDO metadata 3. do rest of whatever being done
right now
The DAS supports this scenario today and can accept Static Types from the
client. But, the purely dynamic scenario is an important one so we must
support both.
Thanks!
Solution 2-2 (temporary if current DAS doesn't take any SDO metadata
yet) 1. deploy the generated SDO metadata from DAS to client, once 2.
do rest of whatever being done right now
On 8/25/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
The RDB DAS creates the graph and corresponding Types dynamically
from the database query results.
Frank Budinsky wrote:
The problem seems to be that the metadata for class DataGraphRoot is
not
registered on the client. Is that the only missing metadata? What
about the metadata for the rest of the model. I can't provide any
more help without more details about how the metadata is being defined.
Frank.
"Kevin Williams" <[EMAIL PROTECTED]> wrote on 08/25/2006 03:30:15 PM:
It may be that your remote client has not initialized the SDO/EMF
environment properly and I think that we need some help from the
SDO team. I have copied this to the dev list since not everyone
has registered yet for the user list.
--Kevin
Luciano Resende wrote:
Hi Scott
So, here is a quick example from our unit testings :
/**
* Read a specific customer
*/
public void testReadSingle() throws Exception {
//Create and initialize command to read customers
DAS das = DAS.FACTORY.createDAS(getConnection());
Command readCustomers = das.createCommand("select * from
CUSTOMER where ID = 1");
//Read
DataObject root = readCustomers.executeQuery();
//Verify
assertEquals(1, root.getInt("CUSTOMER[1]/ID"));
}
If you get a reference to root first, then try to access the
customer information, do you still have this problem ?
Maybe something like this :
DataObject root = readCust.executeQuery(); cust =
root.getDataObject("CUSTOMER")
Please let me know if this helps...
- Luciano
On 8/24/06, *Scott Kurinskas* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi,
Now that my DAS example is up and running, I'm trying to move my
example to
a client/server environment and integrate it with my product. My
use-case
is very simple, a client makes a request to the server, the
server
fetches
the result from the database and returns the DataObject back to
the client.
The server side code looks like the following:
das = DAS.FACTORY.createDAS(getConfig("CompanyConfig.xml"),
connection);
String sql = "Select * from customers where
customers.customerNumber = " +
key;
Command readCust = das.createCommand(sql);
DataObject cust = readCust.executeQuery();
return cust;
The code executes fine on the client but for some reason the
client is
throwing the exception below. The client should be
deserializing
the
response into a DataObject, but for some reason its complaining
about class
DataGraphRoot not found. The same code executing in a app works
great.
Thoughts?
Thanks again,
Scott
Caught unexpected Exception
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Class
'DataGraphRoot' not found.
( file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%20
<file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
20&%20Cache%20
<file:///C:/Documents%20and%20Settings/skurinsk/workspace/SDO%
20&%20Cache%20>
Client/all.datagraph> &%20Cache%20Client/all.datagraph, 5, 22)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.
handleErrors(XMLLoadImpl.java:80)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java
:189)
at
org.apache.tuscany.sdo.util.
DataGraphResourceFactoryImpl$DataGraphResourceIm
pl$LoadImpl.load(DataGraphResourceFactoryImpl.java:452)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.
doLoad(XMLResourceImpl.java
:1
79)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.
load(ResourceImpl.java:1089
)
at
org.apache.tuscany.sdo.impl.
DataGraphImpl$EDataGraphExternalizable.readExter
nal(DataGraphImpl.java:665)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
58)
at
java.io.ObjectInputStream.
readOrdinaryObject(ObjectInputStream.java:1716)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java
:1304)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at
org.apache.tuscany.sdo.helper.
HelperProviderImpl$ResolvableImpl.readDataObje
ct(HelperProviderImpl.java:205)
at
org.apache.tuscany.sdo.helper.
HelperProviderImpl$ResolvableImpl.readExternal
(HelperProviderImpl.java:144)
at
commonj.sdo.impl.ExternalizableDelegator.
readExternal(ExternalizableDelegato
r.java:80)
at
java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:17
58)
at
java.io.ObjectInputStream.
readOrdinaryObject(ObjectInputStream.java:1716)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
at
com.gemstone.gemfire.DataSerializer.readObject(DataSerializer.java:3
200)
at
com.gemstone.gemfire.internal.util.BlobHelper.
deserializeBlob(BlobHelper.jav
a:55
--
-----------------------------------------------------
Luciano Resende
SOA Opensource - Apache Tuscany
-----------------------------------------------------
-------------------------------------------------------------------
-- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
