Hi Scott, We have an implementation that we're currently testing/debugging. We should have it finished in the next couple of days.
Frank. Scott Kurinskas <[EMAIL PROTECTED]> wrote on 09/05/2006 09:40:06 PM: > 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]
