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: tuscany-user@ws.apache.org; tuscany-dev@ws.apache.org 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]
