On Mon, 2002-05-06 at 09:05, Bill Schneider wrote: > I made a patch locally to allow me to use DataSources from JNDI instead of > the default Torque connection pool. I used the Adapter pattern (I think > that's the word for it :-)) to preserve backward compatibility, turning > pool/DBConnection and pool/ConnectionPool into interfaces and copying the > existing classes to ConnectionPoolImpl and DBConnectionImpl. Then I added > two new classes, DataSourceWrapper (implements ConnectionPool) and > ConnectionWrapper (implements DBConnection), which wrap a DataSource and a > java.sql.Connection and adapt them to the Torque APIs. > > I also touched Torque.java to let me specify a database like > > database.mydatabase.resource=jdbc/MyDataSource > > There are three questions that I'd like to discuss here on this list -- > > - is this a reasonable approach? It seems like it would be better for all > Torque code to use java.sql.Connection and javax.sql.DataSource directly, > and eliminate ConnectionPool/DBConnection entirely, since JDBC 2 is the > standard. This would break existing code, though, because all the generated > classes expect Torque.getConnection() to return a DBConnection instead of a > java.sql.Connection.
I created a branch, JDBC2POOL_BRANCH, to do this work. I was planning to merge this post 3.0 release. But the release process is moving very slowly. Maybe it would be better to eliminate DBConnection prior to the release? > > - is there a good way to find out, at runtime, what database you're > connecting to? When all you have is a DataSource and a JNDI resource name, > you have no way of knowing the underlying database, which Torque needs to > know to pick the right database adapter. Is there some magic JDBC query or > escape that lets you figure out your database? (conn.getClass() doesn't > work because it is usually wrapped by the pool, e.g., > org.apache.commons.dbcp.PoolableConnection) > I just introduced a property to specify the database type or adapter. This used to be specified separately from the driver property and tying them together has caused about as many questions as having the two properties. As you point out there is no way (or we have been unable to find a way) to keep the mapping using datasources. > - administrivia: what's the right way to submit a patch if there are new > files that weren't in CVS before? > Adding them as separate attachments is fine. john mcnally -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
