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 Fri, 25 Aug 2006 22:25:04 GMT
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:1758)
>> >
>> >
>> >>>    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:1758)
>> >
>> >
>> >>>    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:3200) 
>>
>> >
>> >
>> >>>    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


Mime
View raw message