Thinking about data binding integration... In the case of transformations like JDBCStreamReader -> JSON -> JDBCStreamReader, will the Data Binding Framework maintain the same structure we are using for the data, as described below ?
> 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 On 10/11/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > 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/ > -- 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]
