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/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
RE: Re: JDBCClient
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
RE: Re: JDBCClient
Jerome, I saw that you had checked in a fix in SVN for the issue I reported. The fix does not fix my problem, however. I believe that the finally-block should be removed completely, and the connection closed elsewhere. It seems to me that the pooling mechanism should keep a lifetime of the connection (eg number of times used), and close the connection and remove from the pool after a certain amount of time. This raises the question on what to do in the case when connections aren't pooled, however. I'm quite busy with work at the moment, but I'll look into setting up my environment for development against the restlet source, so I can submit a fix rather than just ranting on the mailing list :-) BTW, I'm using the JavaDB (derby) as the database to test for, in case that makes any difference. Regards, Kyrre --- Jerome Louvel [EMAIL PROTECTED] wrote: 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
RE: Re: JDBCClient
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
