Hi Kyrre, Thanks for sharing your thoughts: I fully agree with you. We need a higher level of mapping between JDBC database and Restlet Resources. The JDBC connector is a first step at a lower-level.
In 1.1 we will focus on providing this higher-level of mapping where people can manipulation table rows/columns/cells directly as resources with URIs and using GET/POST/PUT/DELETE methods (internally mapped to corresponding SQL verbs). This will be a major effort in order to get this mapping right and will bring us closer to other frameworks like Rails which introduced a similar feature in their 1.2 RC1 release: http://weblog.rubyonrails.com/2006/11/23/rails-1-2-release-candidate-1 I've also just added an XSLT Filter (called org.restlet.Transformer) that will facilitate the task of transforming the JDBC XML resultsets (or any XML document) into a representation (XML, HTML, etc.) suitable for the clients. Stay tuned! Jerome > -----Message d'origine----- > De : Kyrre Kristiansen [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 24 novembre 2006 10:24 > À : discuss@restlet.tigris.org > Objet : RE: Re: JDBCClient > > Hi. > > Just some thoughts around JDBCClient. > > I have to say that I was a bit surprised when I saw > the implementation of JDBCClient as it is. > > What I had envisioned was an implementations that used > a basic mapping from methods to SQL keywords, eg > SELECT, INSERT, UPDATE and DELETE (CRUD, remember?), > with the rest of the information in the input > representation. > > I think that returning the entire result set in XML > will limit the size of the result returned from the > database, although it probably would suffice for most > database queries used in real-life applications. As > network access is horrendously expensive compared to > doing something locally (memory/disk), it is usually > better to pin down the result as much as possible in > the database before returning it to the application. > At least that was what my database lecturer told me > back in the happy student days. > > Regards, > Kyrre > > --- Jerome Louvel <[EMAIL PROTECTED]> wrote: > > > > > Hi John, > > > > > I have some concerns about the proposed > > approach... > > > > > > (A) What about results that are quite large? I.e. > > that take up a lot > > > of memory or won't fit into memory? > > > > One major use case I see for this JDBC connector is > > to fetch a reasonable > > amount of data in order to assemble a representation > > for a client of a > > Restlet application. This representation might be in > > XML, HTML, PDF, RTF, > > ... or any other format that can be generated from > > an XML source. As for > > memory, we will rely on streams. When the > > representation is fully consumed, > > the stream or channel should be closed, which will > > transparently release the > > JDBC connection. > > > > The result XML format will use the WebRowSet > > implementation for now: > > > http://java.sun.com/j2se/1.5.0/docs/api/javax/sql/rowset/WebRo > wSet.html > > > > A useful piece, will be the addition of an > > XsltFilter later in 1.1: > > http://restlet.tigris.org/issues/show_bug.cgi?id=112 > > > > > (B) What about performance? Doing that extra > > transformation > > > is costly. > > > > There is always the option to use JDBC APIs > > directly. If you need to built > > business object from this JDBC data, obviously using > > a solution like EJB or > > JPA/Hibernate seems even better. > > > > > (C) What about those of use who really don't want > > to have to bother > > > with yet still more XML in the system? > > > > If people want to keep the current approach (XML > > request and JdbcResult > > response) we will preserve it and provide an option > > to switch between the > > two types of results (XML or JdbcResult wrapper). > > > > > > The main reason of this refactoring is that > > keeping an open > > > connection does > > > > not really comply with a REST approach. > > > > > > Yes and no. The purpose, IMHO, is for the service > > to bridge from a > > > purely REST to the messiness of things like > > databases. > > > > I think we all agree that this is a bridge more than > > a pure connector (JDBC > > doesn't define a standard protocol anyway). > > Hopefully the approach proposed > > above will coverage most use cases for this > > connector. > > > > Another road we could explore is the SQL/XML > > standardization efforts that > > allow an RDBMS to directly return results as an XML > > stream, without any > > intermediary transformation. See: > > http://restlet.tigris.org/issues/show_bug.cgi?id=7 > > > > Also, I'd like to explore the usage of XQuery to > > access databases in the > > future: > > http://restlet.tigris.org/issues/show_bug.cgi?id=8 > > > > Finally, we should also investigate the idea of a > > DatabaseHandler/Connector > > that will attempt to map as well as possible table > > rows and columns to a set > > of resources/representations, using a flexible URI > > namespace. It would > > support GET/PUT/DELETE/POST. See initial thoughts > > here: > > http://restlet.tigris.org/issues/show_bug.cgi?id=6 > > > > Best regards, > > Jerome > > > > > ------------------------------------------------------------ > Kyrre Kristiansen > > > > ___________________________________________________________ > Try the all-new Yahoo! Mail. "The New Version is radically > easier to use" The Wall Street Journal > http://uk.docs.yahoo.com/nowyoucan.html
