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 ? On 10/3/07, Douglas Leite <[EMAIL PROTECTED]> wrote: > Although I'm a novice in the Tuscany project, I'm interested in help to > improve the implementation-data module. So, do you have some suggestion to > give me about how I can start? > > Thanks, > > Douglas Leite > > On 10/3/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > I'm fine with most of what is said here, one component per database > > and one service per table is fine. In this context, JDBC is probably > > good enough, except for handling OCC as the data or feeds are going to > > work in a disconnected way. > > > > I also see this evolving in the near future, to be more sophisticated, > > providing support for all CRUD operations and pre-defined queries > > where data from multiple table are combined together; you will > > probably want some OCC support, and support for managed versus > > un-managed environments, then I think we should use some kind of > > framework that already handles some of these complexity for us. > > > > Some more thoughts/comments inline : > > > > > > On 10/2/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > I'd like to start using the implementation-data extension in the Store > > > sample, first to have the contents of the sample Catalog in a database, > > > then maybe extend it to the ShoppingCart as well. > > > > > +1, but be aware that right now there is only support for read, > > expanding the support of CRUD operations > > > > > In that context, I'm thinking about evolving the implementation-data > > > extension a little, along the following lines: > > > > > > - One component per database so we don't have to repeat the database > > > connection info in each component. > > > > > > > +1 > > > > > - One service per table, named like the table, so we don't have to know > > > a fixed service name and also when you look at the service it's obvious > > > which table it works with. > > > > > > > +1 > > > > > - Experiment with using JDBC directly, as we already have > > > implementation-das to leverage the DAS/SDO runtime. > > > > > > - Taking and returning an StAX XMLStreamReader, as it'll be sufficient > > > (and really lightweight) if the Tuscany databinding framework can > > > convert that XML data to whatever databinding is needed by other > > > components in the assembly. > > > > > > > Could you elaborate more ? Is your proposal to, internally, use StAX > > XMLStreamReader, but no changes on the client side, is this right ? > > Would it cause too much transformation JDBC -> XMLStreamReader -> Some > > kind of object and vice versa ? What benefits you see here ? > > > > Do we also need a Feed databinding to help expose data as feeds ? > > > > > Thoughts? > > > > > > -- > > > 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] > > > > > -- 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]
