With the data being manipulated like a XmlStreamReader, I suppose that a good way to implement the update operator is use a stream that contains the modifications. Something like that:
int update(XmlStreamReader modifications); Therefore, the 'modifications' stream will cotain all the modifications made in the stream retrieved from the get operator. However, in the scenary where we have a simple java developer, how is he supposed to manipulate the stream reader ? What about a XmlStreamReader that allow some sets methods? On 10/12/07, Douglas Leite <[EMAIL PROTECTED]> wrote: > > As suggested, I've made some improvements in the sample store. Now the > catalog data is accessed by JDBC instead of a hardcoded table in memory. > (https://issues.apache.org/jira/browse/TUSCANY-1844 > ) > > After running the sample with the property currencyCode configured as > 'EUR', in the store.composite, I got an float parse error in the getTotal > method in the ShoppingCartImpl. Because of that, I've changed a little the > way of get the price of each product. > > Suggestion? > > On 10/12/07, Raymond Feng <[EMAIL PROTECTED]> wrote: > > > > 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: < [email protected]> > > 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://people.apache.org/%7Elresende> > > > 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] > > > > >
