tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Williams" <kevin...@qwest.net>
Subject Re: DataObject/DataGraph Serialization & DataGraphRoot
Date Thu, 07 Sep 2006 19:10:57 GMT
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:kevincbw@qwest.net] 
>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 <kevincbw@qwest.net> 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" <kevincbw@qwest.net> 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* <scott.kurinskas@gemstone.com 
>>>>>><mailto:scott.kurinskas@gemstone.com>> 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: tuscany-user-unsubscribe@ws.apache.org
>>>>>For additional commands, e-mail: tuscany-user-help@ws.apache.org
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>--------------------------------------------------------------------
>>>>- To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: tuscany-user-help@ws.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: tuscany-user-help@ws.apache.org
>>>
>>>
>>>      
>>>
>>    
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
>For additional commands, e-mail: tuscany-user-help@ws.apache.org
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org


Mime
View raw message