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/WebRowSet.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
