Hi,
To better support the XML streaming from the database and other source such
as SDO or DOM, I added a prototype to create XMLStreamReader from a tree
structure. You can find the code in tuscany-databinding module
(org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java). I'm
trying to implement the XMLStreamReader from the DOM tree based on this new
class and will keep you updated.
Luciano, can you take a brief look to see if you can use it to stream the
records?
Thanks,
Raymond
----- Original Message -----
From: "Luciano Resende" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Thursday, October 11, 2007 6:45 PM
Subject: Re: [DISCUSS] Evolving Implementation-data
I have finished a strawman for implementation.data going in the
directions discussed here (revision #584019) :
- One component per database
- One service per table
- Tables are introspected from database metadata
- Fixed service interface, right now supporting get and get(id) only
- Implemented using JDBC
- The results are now streamed directly from the database using a
JDBCResultSetStreamReader
I've took the following conventions to produce the Table XML Elements :
Root : <[table_name]_table> element
Records : <[table_name]> element
Columns : <column name>
Column values: column value as element text
Next todos...
- Expand the interface to support all CRUD Operations
- Enhance JDBCResultSetStreamReader as needed
- Filter system tables from available services (or not ???)
- Integrate and test with databinding
- Integrate with samples (store, xmlquery)
Please, take a look and provide your comments...
Thinking a little bit in the future, and how they data services would
be exposed as web-services, what do you guys think about integrating
it with wsdl-less webservices feature we have, to allow wsdl
generation by introspecting the database schema ? Thoughts ?
On 10/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Luciano Resende wrote:
> Hey Douglas
>
> Thanks for volunteering, maybe you could start by prototyping the
> JDBC version of implementation-data that would return a
> XMLStreamReader. Once we flush out the design details, then we could
> think about the other CUD operations.
>
> Sebastien, and others... Thoughts ?
>
>
It might be even better to start from a sample, without even using
implementation-data at the beginning.
I'd suggest the Online Store sample under samples/store, try to change
CatalogImpl.java component to get the Catalog from a database using JDBC
(instead of a hardcoded table in memory), and return either an
XMLStreamReader or the current Item objects.
Then try the same thing with the ShoppingCartImpl component, this will
help us understand what to do for updates, deletes etc.
Then once we've been through that sample we'll probably have a clearer
idea of what implementation-data needs to do... basically automate what
we wrote by hand in the sample.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
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]
