Here is a first version of the implementation proposed: https://issues.apache.org/jira/browse/TUSCANY-2297
I've added the Collection interface support to the implementation-data-xml, where the logic of the put, post, get, and delete methods are, basically, the same of the update, insert, get, and delete methods, respectively, provided by DATA interface. An implementation-data-xml component supports now two service interfaces: DATA and Collection. I am not sure, but after the results I got, I realize that an component cannot have two or more interfaces with the same name, even though those have different types. Hence, I've adopted this pattern: - DATA service: table name+_DATA; - Collection service: table name; Suggestions? On Thu, Apr 24, 2008 at 2:56 PM, Douglas Leite <[EMAIL PROTECTED]> wrote: > I agree with you. Changing the return type of put and delete methods > wouldn't be useful for all kinds of situations. > To this first version I will let the implementation-data-xml support both > interfaces DATA and Collection. > > > On Thu, Apr 24, 2008 at 1:48 PM, Luciano Resende <[EMAIL PROTECTED]> > wrote: > > > On Thu, Apr 24, 2008 at 8:30 AM, Douglas Leite <[EMAIL PROTECTED]> > > wrote: > > > I have started to integrate the Collection interface with > > > implentation-data-xml. Although the methods present in the DATA > > interface > > > (get, insert, update, delete) can be replaced by the Collection > > interface's > > > methods (get, post, put, delete), there are some differences. The > > update and > > > delete DATA methods return the number of rows affected by each > > method. On > > > the other hand, this feature is not present using the Collection > > methods, > > > because put and delete are void. > > > > > > > I guess what you are describing here is a side effect of Collection > > being a more REST based interface and designed to perform put and > > delete on a given resource, when the current DATA interface allows for > > manipulating multiple rows at a time. Maybe we could have the > > implementation-data-xml to support both DATA and Collection > > interfaces, and let time and integration with real scenarios decide > > witch one would be more useful. > > > > > Would be better change the signature of the put and delete > > Collection > > > methods, allowing a K type return, or let a impl-data-xml component > > has the > > > two interfaces? > > > > > > > I got a little confused here, as returning K (they key type) wouldn't > > solve the first issue you raised. Anyway, looking at the current > > Collection interface, key is used as a parameter thus known to the > > caller. > > > > void put(K key, D item) throws NotFoundException; > > > > void delete(K key) throws NotFoundException; > > > > Then, I'm not sure about the benefits of changing it to return K. > > > > > On Tue, Apr 15, 2008 at 5:06 PM, Luciano Resende < > > [EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > I'd suggest the following as the next steps around > > implementation-data-xml > > > > > > > > - Add support for data collection interface from > > implementation-data > > > > - At this point, integration with binding-atom-abdera should be > > > > working, it would be great to integrate this with our store > > tutorial, > > > > either by enhancing the catalog-db or by creating a new module > > > > catalog-db-xml. > > > > - The exercise above should also help drive the requirements for > > > > database schema that you are proposing with a concrete scenario. > > > > > > > > Thoughts ? > > > > > > > > On Tue, Apr 15, 2008 at 12:14 PM, Douglas Leite < > > [EMAIL PROTECTED]> > > > > wrote: > > > > > In my last contribution, I have proposed a first version of > > Update and > > > > > Insert methods for impl.data.xml component. > > > > > One of the insert method limitations is that the table must only > > have > > > > > columns which types are char or varchar. However, I want to > > improve > > > > this, > > > > > allowing any sql primitive type. > > > > > The fact is, the syntax to insert a varchar, for example, is > > different > > > > to > > > > > insert a integer. So, it's necessary to know the types of the > > column. > > > > > I could resolve this problem in, at least, to different ways: > > First, I > > > > could > > > > > use metadata information on the InsertInvoker, and discover the > > types of > > > > > columns. Another way to do this, is to add the column type > > information > > > > in > > > > > the xml stream retrieved by the get method. So, we would have > > something > > > > like > > > > > this: > > > > > > > > > > <resultSet> > > > > > <record> > > > > > <column name="NAME" type="VARCHAR">New Coorporation > > I</column> > > > > > <column name="PHONE" > > type="INTEGER">+5511990202146</column> > > > > > . . . > > > > > </record> > > > > > </resultSet> > > > > > > > > > > I am not sure if other metadata informations should be added to > > the xml > > > > > stream. But, at the moment, I think that column type would be > > useful. > > > > > > > > > > Thoughts? > > > > > > > > > > -- > > > > > Douglas Siqueira Leite > > > > > Computer Science Master's degree student of University of > > Campinas > > > > (Unicamp) > > > > > > > > > > > > > > > > > > > > > -- > > > > Luciano Resende > > > > Apache Tuscany Committer > > > > > > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>< > > http://people.apache.org/%7Elresende> > > > > http://lresende.blogspot.com/ > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > > > > > > > Douglas Siqueira Leite > > > Computer Science Master's degree student of University of Campinas > > (Unicamp) > > > > > > > > > > > -- > > Luciano Resende > > Apache Tuscany Committer > > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> > > http://lresende.blogspot.com/ > > > > > > -- > Douglas Siqueira Leite > Computer Science Master's degree student of University of Campinas > (Unicamp) > -- Douglas Siqueira Leite Computer Science Master's degree student of University of Campinas (Unicamp)